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PATENT APPLICATION 
09/811,239 



REMARKS 

This Application has been carefully reviewed in light of 
the Office Action dated December 30, 2006. In order to 
advance prosecution of this Application, Claims 1-12 and 18 
have been amended. Applicant respectfully requests 

reconsideration and favorable action for this Application. 

The Information Disclosure Statement of June 27, 2 005 
stands objected to under 37 C.F.R. §1. 98(a) (2) for failing to 
provide a legible copy of Document G cited in Form PTO 144 9 
associated therewith. Applicant respectfully submits that the 
identified Document G was included with the Information 
Disclosure Statement of June 27, 2005. For the convenience of 
the Examiner, attached herewith is another copy of the 
identified Document G. Applicant respectfully requests that 
the Information Disclosure Statement of June 27, 2005 be 
considered by the Examiner in this Application. 

Claims 1-24 stand rejected under 35 U.S.C. §102 (b) as 
being anticipated by Armitage, et al . Independent Claims 1 
and 13 recite in general an ability to receive a time division 
multiplexed data stream at an ingress end, divide said data 
stream into a set of fixed sized packets, add a service header 
to each of said packets, and add an additional header on top 
of said service header in accordance with MPLS protocols. By 
contrast, the Armitage, et al . paper fails to mention a time 
division multiplexed data stream let alone an ability to 
receive and divide it into fixed sized packets, add a service 
header, and add a MPLS header as provided by the claimed 
invention. The portions of the Armitage, et al . patent cited 
by the Examiner merely refer to placing a MPLS frame into the 
native frame format of a packet -based link, such as a Point - 
to-Point Protocol link cited as an example therein. Thus, the 
Armitage, et al . patent is concerned with forwarding MPLS 
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frames over a packet -based link and has no disclosure 
whatsoever with respect to forwarding a TDM stream in a MPLS 
network as contemplated by the claimed invention. Therefore, 
Applicant respectfully submits that Claims 1-24 are not 
anticipated by the Armitage, et al . paper. 
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CONCLUSION 

Applicant has now made an earnest attempt to place this 
Application in condition for allowance. For the foregoing 
reasons and for other reasons clearly apparent, Applicant 
respectfully requests reconsideration and full allowance of 
all pending claims. 

The Commissioner is hereby authorized to charge any 
amount required or credit any overpayment to Deposit Account 
No. 02-0384 of BAKER BOTTS l.l.p. 

Respectfully submitted, 
BAKER BOTTS l.l.p. 




Charles S. Fish 
Reg. No. 35,870 



March 30, 2006 
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1. Introduction 

There is a user demand for carrying certain types of constant bit rate (CBR) or "circuit" 
traffic over Asynchronous Transfer Mode (ATM) networks. As ATM is essentially a 
packet- rather than circuit-oriented transmission technology, it must emulate circuit 
characteristics in order to provide good support for CBR traffic. 

A critical attribute of a Circuit Emulation Service (CES) is that the performance realized 
over ATM should be comparable to that experienced with the current PDH/SDH 
technology. 

1.1 Purpose of Document 

This document -- referred to as the Circuit Emulation Service Interoperability 
Specification (CES-IS) — specifies the ATM Forum's interoperability agreements for 
supporting CBR traffic over ATM networks that comply with the Forum's other 
interoperability agreements. 

Note that all of the specific types of CBR service and/or specific interfaces identified 
within this document need not be supported in order to be compliant with this 
specification. Although no specific type of CBR service nor specific interface is required 
for compliance, support for any one or more of these will be considered as implementing a 
Circuit Emulation Service. However, if support for any of the specified types of CBR 
service and/or specific interfaces identified within this specification is provided, this 
support must then be provided in a manner consistent with this specification to be 
considered compliant. 

For example, a compliant CES implementation may choose to implement a Structured DS1 
Nx64 kbit/s Service and an Unstructured DS1 Service without implementing any El, J2 or 
other service. This implementation would then be considered compliant for Structured DS1 
Nx64 kbit/s Service and Unstructured DS1 Service, provided that these services are 
implemented in a manner consistent with their specification within this document. 

1.2 Scope of Document 

The CES-IS specifically covers the following types of CBR service: 

1. Structured DS1/E1 Nx64 kbit/s (Fractional DS1/E1) Service 

2. Unstructured DS1/E1 (1.544 Mbit/s, 2.048 Mbit/s) Service 

3. Unstructured DS3/E3 (44.736 Mbit/s, 34.368 Mbit/s) Service 

4. Structured J2 Nx64 kbit/s (Fractional J2) Service 

5. Unstructured J2 (6.3 1 2 Mbit/s) Service 

The Structured Nx64 and Unstructured DS1/E1/J2 services described in this document 
offer two ways to connect DS1/E1/J2 equipment across emulated circuits carried on an 
ATM network. The two techniques can be used to solve different kinds of problems: 
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The Structured DS1/E1/J2 Nx64 service is modeled after a Fractional DS1/E1/J2 circuit, 
and is useful in the following situations: 

1 . The Nx64 service can be configured to minimize ATM bandwidth, 
by only sending the timeslots that are actually needed. 

2. The Nx64 service provides clocking to the end-user equipment, so it 
fits into a fully-synchronous network environment. 

3. Because it terminates the Facility Data Link, the Nx64 service can 
provide accurate link quality monitoring and fault isolation for the 
DS1/E1 link between the IWF and the end-user equipment 

The Unstructured DS1/E1/J2 Service provides transparent transmission of the DS1/E1/J2 
data stream across the ATM network and is modeled after an asynchronous DS1/E1 leased 
private line. It allows for the following situations: 

1. End-user equipment may use either standard (SF, ESF, G.704 or JT- 
G.704) or non-standard framing formats. 

2. When end-to-end communication of the Facility Data Link or Alarm 
states is important. 

3. When timing is supplied by the end-user DS 1/E1/J2 equipment and 
carried through the network. The end-user equipment may or may 
not be synchronous to the network. 

The Unstructured DS3/E3 Service provides basic DS3/E3 Circuit Emulation Service and 
allows for the following situations: 

1 . Standard or non-standard framing may be used by the end-user DS3/E3 equipment. 

2. End-to-end communication of P-Bit, X-Bit and C-Bit channels is provided. 

3. Timing is supplied by the end-user DS3/E3 equipment and carried through the 
network. The end-user equipment may or may not be synchronous to the network. 

The scope of the CES-IS is limited to the essential agreements needed to reliably transport 
these bit rates across ATM networks that comply with the ATM Forum's interoperability 
agreements. Specifying all the agreements needed to support a full service offering (for 
example, ATM-based video telephony) is explicitly beyond the scope of this document. 

1.3 Structure of Document 

Section 1 is an introduction and contains some technical material relating to all types of 
service. Sections 2, 3 and 4 cover Structured DS1/E1/J2 Nx64 kbit/s, Unstructured 
DS1/E1/J2 and Unstructured DS3/E3 Service, respectively. Each of these sections covers 
the following topics: 

1 . Service description 

2. Service-specific AAL 1 requirements (e.g., clocking and error 
recovery) 
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3. AAL user entity requirements (e.g., data coding/formatting, 
signalling) 

Section 5 discusses service-specific ATM Layer requirements (e.g., cell rate and delay 
requirements), section 6 describes ATM signalling parameters, section 7 describes ATM 
call initiation procedures, and section 8 discusses the management of the CES service. 

1.4 Terminology 

This document uses three levels for indicating the degree of compliance necessary for 
specific functions, procedures and coding associated with the Circuit Emulation 
specification: 

• Requirement (R-n): Functions, procedures and coding necessary for 
operational compatibility. 

• Conditional Requirements (CR-n): Functions, procedures and 
coding necessary providing the specified optional function is 
implemented. 

• Option (O-n): Functions, procedures and coding that may be useful, 
but are not necessary for operational compatibility. 



Page 3 of 93 



af-vtoa-0078.000 



CES-IS V2.0 



Introduction 



1.5 Reference Model and Terms 



CBR Service 
Interface 



CBR 
Equipment 



ATM Constant Bit-Rate 
Virtual Channel 



ATM CES 
Interworking 
Function 



ATM CES 
Interworking 
Function 



ATM Access Interface 
a) CES IWFs with CES-IS-Specified Physical DS1/DS3, J2 or E1/E3 Service Interfaces 



CBR Service 
Interface 




CBR 
Equipment 



ATM CES 
Interworking 
Function 



ATM Constant Bit-Rate 
Virtual Channel 




ATM CES 
Interworking 
Function 



ATM Access Interface 



b) CES IWFs with Unspecified Service Interfaces ("Logical" Service) 

Figure 1-1: Circuit Emulation Service Reference Model 

Figure 1-1 provides a reference model for circuit emulation services. Figure 1-la) pictures 
two ATM Circuit Emulation Service (CES) Interworking Functions (IWFs) connected to 
an ATM network via physical interfaces defined in the ATM Forum UNI Specification. 
The CES IWFs are also connected to standard constant bit-rate (CBR) circuits (e.g., 
DS1/DS3, J2 or E1/E3). The job of the two IWFs is to extend the constant bit-rate circuit 
to which they are connected across the ATM network. They are to do this in a manner that 
is transparent to the terminating equipment of the CBR circuit. This means that the ATM 
portion of the connection should retain its bit integrity - i.e., analog signal loss can not be 
inserted and voice echo control cannot be performed. Thus for facilities intended to carry 
voice or multimedia services, any required echo control must be performed either by the 
terminal equipment or before the ATM CES IWF is encountered. The assumption in the 
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CES-IS is that using AAL 1 over ATM constant bit-rate virtual channels is a simple, 
general, and effective method of addressing this type of application. 

Figure 1-lb) shows a similar arrangement, but does not make any external physical 
interfaces explicit. This is intended to show that CES can be used to provide a "logical" 
structured or unstructured DS1/DS3/E1/E3/J2 service, even if that service is not used to 
bridge between existing traditional DS1/DS3, J2 or E1/E3 based circuits. It is also possible 
that one IWF would interface to a DS1/DS3, J2 or E1/E3 based circuit and the other would 
not. 

1.6 References 

1.6.1 Normative 

UNI 3.1, ATM Forum User-Network Interface (UNI) Specification 

af-bici-0013.003, ATM Forum Broadband Intercarrier Interface (B-ICI) Specification v2.0 

ANSI Tl.630-1993, B-ISDN ATM Adaptation Layer CBR Services 

ANSI T 1.627- 1993, B-ISDN ATM Layer Functionality and Specification 

ITU-T 1.356- 1 993 B-ISDN ATM layer cell transfer performance 

ITU-T 1.362-1993 B-ISDN ATM adaptation layer (AAL) functional description 

ITU-T 1.363.1 1996, B-ISDN ATM Adaptation Layer (AAL) Specification, Types 1 and 2 

ANSI Tl. 101-1994, Synchronization Interface Standard 

ANSI Tl. 102-1993 Revised - Digital Hierarchy — Electrical Interfaces 

ANSI T 1.107-1995, Digital Hierarchy - Formats specifications 

ANSI Tl. 403-1995, Carrier-to-Customer Installation — DS1 Metallic Interface 

ANSI T 1 .404- 1 994, Carrier-to-Customer Installation - DS3 Metallic Interface 
Specification 

ANSI T 1.408- 1990, Integrated Services Digital Network (ISDN) Primary Rate - 
Customer Installation Metallic Interfaces Layer 1 Specification 

ANSI T 1.5 10- 1994, Network Performance Parameters for Dedicated Digital Services — 
Specifications. 

ITU-T G.824-1993, The control of jitter and wander within digital networks which are 
based on the 1544 kbit/s digital hierarchy 

Bellcore TR-NWT-000170, Issue 2, January, 1993, Digital CrossConnect System Generic 
Requirements and Objectives 
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ITU-T G.702-1988 Digital hierarchy bit rates 

ITU-T G.703-1991 Physical/electrical characteristics of hierarchical digital interfaces 

ITU-T G.704-1995 Synchronous frame structures used at 1544, 6312, 2048, 8488 and 
44736 kbit/s hierarchical levels 

ITU-T G. 707- 1996 Network node interface for the synchronous digital hierarchy (SDH) 

ITU-T G.823-1993, The control of jitter and wander within digital networks which are 
based on the 2048 kbit/s digital hierarchy 

IETF RFC 1573, Evolution of Interfaces Group of MIB-II, January 1994. 

IETF RFC TBD, Definitions of Managed Objects for the DS3/E3 Interface Type, Date 
TBD. 

IETF RFC TBD, Definitions of Managed Objects for the DS1, El, DS2 and E2 Interface 
Types, Date TBD. 

IETF RFC TBD, Definitions of Managed Objects for the DSO and DSO Bundle Interface 
Types, Date TBD. 

IETF RFC 1595, Definitions of Managed Objects for the SONET/SDH Interface Type, 
March 1994. 

TTC Recommendation JT-G.704, Synchronous Frame Structures Used at Primary and 
Secondary Hierarchical Levels. 

TTC Recommendation JT-G.703a, Secondary Rate User-Network Interface of Leased Line 
- Layer 1 Specification. 

ISO/IEC 1 1573 (1994), Synchronization methods and technical requirements for Private 
Integrated Services Networks. 

1.6.2 Informative 

ETSI ETS 300 353 B-ISDN ATM adaptation layer (AAL) specification type 1 

Bellcore GR-1 1 13-CORE, Issue 1, July, 1994, Asynchronous Transfer Mode (ATM) and 
ATM Adaptation Layer (AAL) Protocols 

Bellcore GR-1 1 10-CORE, Issue 1, August 1994, Broadband ISDN Switching Systems 
Generic Requirements 

Bellcore TA-TSV-001409, Issue 1, November 1993, Generic Requirements for Exchange 
Access PVC Cell Relay Services. 

DTR/NA-52622 Optional aspects of AAL type 1 
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ANSI T1.51 1-1994, B-ISDN ATM Layer Cell Transfer Performance Parameters. 



1.7 ATM Physical Interfaces 

An ATM UNI physical interface has two characteristics that are relevant when supporting 
CES Service: 

1 . Bandwidth - the ATM interface must provide adequate bandwidth to 
carry Nx64 or Unstructured traffic after segmentation. 

2. Timing - the ATM interface can be used to convey timing traceable 
to a Primary Reference Source from the ATM network to the CES 
Interworking Function, where external connection to network timing 
is not supported. 
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2. Structured DS1/E1/J2 Nx64 kbit/s Service 

A number of applications currently use Nx64 kbit/s services. For example, there are a 
number of DTE interfaces and video codecs that are capable of operating at Nx64 kbit/s 
rates for N>1. Within this section, the following conventions apply: 

Nx64 Service = All modes of the Structured DS1/E1 and J2 Nx64 kbit/s Service. 

DS1 Nx64 Service = All modes of Structured DS1/E1/J2 Nx64 kbit/s Service in which the 
two IWFs involved are emulating DS1 -based Nx64 kbit/s service supplied via a DSX-1 
interface, T 1.102-1993 Revised. 

El Nx64 Service = All modes of Structured DS1/E1/J2 Nx64 kbit/s Service in which the 
two IWFs involved are emulating El-based Nx64 kbit/s service supplied via a G.703 
interface. 

J2 Nx64 Service = All modes of Structured DS1/E1/J2 Nx64 kbit/s Service in which the 
two IWFs involved are emulating J2-based Nx64 kbit/s service supplied via a JT-G.703a 
interface. 

DS1 Nx64 Basic Service = DS1 Nx64 Service with no support for carrying channel 
associated signaling (CAS). 

El Nx64 Basic Service = El Nx64 Service with no support for carrying CAS. 

J2 Nx64 Basic Service = J2 Nx64 Service with no support for carrying CAS. 

DS1 Nx64 Service w/CAS = DS1 Nx64 Service with support for carrying CAS. 

El Nx64 Service w/CAS = El Nx64 Service with support for carrying CAS. 

J2 Nx64 Service w/CAS = J2 Nx64 Service with support for carrying CAS. 

Logical Nx64 Service = All modes of Structured DS1/E1/J2 Nx64 kbit/s Service in which 
the non- ATM-related functions of the two IWFs involved are left unspecified. 

Logical Nx64 Basic Service = Logical Nx64 Service with no support for carrying CAS. 

Logical Nx64 Service w/CAS = Logical Nx64 Service with support for carrying CAS. 

Figure 2-1 shows the relationships among the members of the Nx64 Services family. 

Nx64 Service 



Service Interface Type DS1 El J2 Logical 

^ Basic \ Basic \ Basic \ Basic 

Support for CAS 

w/CAS w/CAS w/CAS w/CAS 

Figure 2-1: N64 Service Taxonomy 
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Note that the above conventions do not include any indication of specific support for CCS 
(Common Channel Signalling) services. The current version of this specification makes no 
particular provisions for its use in CCS systems, but this specification does not preclude its 
use in CCS systems. Specific provisions for its use in CCS systems are for further study. 

2.1 Service Description 

Nx64 Service is intended to emulate a point-to-point Fractional DS1, El or J2 circuit. The 
service is typically accessed via either 1.544 Mbit/s DSX-1 (T1.102 - 1993 Revised) 
interfaces, 2.048 Mbit/s (G.703) interfaces or 6.312 Mbit/s (JT-G.703a) interfaces. For 
DS1, N of the 24 timeslots available at the DSX-1 interface, where 1 < N < 24, are carried 
across the ATM network and reproduced at the output edge. For El, 1 <N < 3 1 . For J2, 1 
<N<96. 

Because the Nx64 Service can be configured to use only a fraction of the timeslots 
available on the Service Interface, it is possible to allow several independent emulated 
circuits to share one Service Interface, as shown in Figure 2-2. The capability of allowing 
several AALl Entities to share one Service Interface, where each AALl Entity is 
associated with a different Virtual Channel Connection (VCC), allows for functional 
emulation of a DS1/DS0, El/ DSO or J2/DS0 Digital CrossConnect Switch. 



ATM Interface 
(one or more VCCs) 




m CBR Service 
Interface 



Shaded area is 
referred to as 
"AAL User Entity" 



Associated with 
circuit being emulated 



Figure 2-2: DS1/E1/J2 Structured Service 
Interworking Function - Layering Perspective 



In this configuration: 



1 . The ATM layer is responsible for multiplexing and demultiplexing 
several VCCs, one to each AALl Entity. 
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2. Each AAL1 Entity is responsible for performing segmentation and 
reassembly on one VCC. 

3. The Timeslot Mapping Function is responsible for assigning the 
stream input and output from the SAR process to specific time slots 
in the Service 

Figure 2-3 shows an example crossconnect configuration in which two PBXs are connected 
across an ATM backbone to a Central Office switch. One virtual channel might carry 10 
timeslots between one PBX and the Central Office switch; another virtual channel might 
carry 10 timeslots between the other PBX and the Central Office Switch. At the pair of 
IWF's near the Central Office switch, the two virtual channels are reassembled, and a total 
of 20 timeslots are carried across the last DS1/E1/J2 link connecting the Central Office 
switch and its CES IWF. Although the Nx64 Service should be useful in providing a 
crossconnect service, it is outside the scope of the current CES-IS to specify crossconnect 
service, such as that defined in Bellcore TR-NWT-000170. 

DS1/E1/J2 links . DS1/E1/J2 Link 




Note: This is an example of a pair of CES 
Interworking Functions within a 
node, sharing access to physical 
interfaces 



Figure 2-3: Crossconnect Example 
(R-l) A CES IWF providing Nx64 Service shall provide one AAL1 Entity. 

(O-l) Multiple CES IWF's providing Nx64 Service may be used to provide multiple 
AAL1 Entities, allowing several Nx64 connections to be multiplexed onto a single service 
interface, with each connection utilizing different 64 kbps channels of the service interface. 

2.1.1 Framing 

(R-2) DS1 Nx64 Service shall be capable of interfacing with circuits using Extended 
Superframe Format. 
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(0-2) DS1 Nx64 Service may provide SF framing at a DS1 Service Interface. 

(R-3) El Nx64 Service shall be capable of interfacing with circuits using G.704 framing. 

(R-4) J2 Nx64 Service shall be capable of interfacing with circuits using JT-G.704 
framing. 

2.1.2 Timeslot Assignment 

(R-5) The Nx64 Service shall carry any group of N 64 kbit/sec timeslots, where N can be 1 
to 24, 1 to 3 1, or 1 to 96 for DS1/E1 and J2 respectively. 

The timeslots assigned to a virtual channel are not required to be contiguous. Timeslots are 
assigned to a virtual circuit by MIB variables, and it should be noted that the assignment of 
timeslots is not required to be the same on the input and output ends of the virtual channel. 
Even though the timeslot assignment on input and output may be different, the CES IWFs 
must deliver octets at the output in the same order as they were received at the input. The 
Nx64 service also must maintain 125-|isec frame integrity across a virtual channel. For 
example, given a 2x64 kbit/s emulated circuit, two octets that are sent into the input IWF's 
Service Interface in one frame shall be delivered at the output IWF's Service Interface in 
one frame, and in the same order. 

2.1.3 Clocking 

The DS1/E1/J2 Nx64 kbit/s Service requires the use of synchronous circuit timing, as 
recommended by ITU 1.363. 1 . In order to support this synchronous clock recovery by the 
attached end-user equipment, the following requirements are stated: 

(R-6) Any Nx64 Service IWF shall provide a means by which a timesource traceable to a 
Primary Reference Source (PRS) may be supplied. 

(R-7) For DS1 Service, an IWF Service Interface shall provide 1.544 MHz timing to 
external DS1 equipment. 

(R-8) For El Nx64 Service, an IWF Service Interface shall provide 2.048 MHz timing to 
external El equipment. 

(R-9) For J2 Nx64 Service, an IWF Service Interface shall provide 6.312 MHz timing to 
external J2 equipment. 

These requirements assume that the IWF provides the required synchronous circuit timing 
to the external equipment via the CES service interface itself. Note, however, that this does 
not preclude the provision of the synchronous circuit timing to the external equipment via 
a separate physical interface. The specification of such a separate timing interface is 
beyond the scope of this specification. 

Section 2.4 gives more information about clock distribution techniques. 
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2.1.4 Jitter and Wander 

(R-10) Jitter measured at the output of the IWF Service Interface and tolerated at the input 
of the IWF Service Interface must meet ANSI T1.403 and G.824 for DS1 circuits. 

(R-ll) Wander must meet ANSI Tl .403 and G.824 for DS1 circuits. 

(R-12) Jitter measured at the output of the IWF Service Interface and tolerated at the input 
of the IWF Service Interface must meet G.823 for El circuits. 

(R-13) Wander must meet G.823 for El circuits. 

(R-14) Jitter measured at the output of the IWF Service Interface and tolerated at the input 
of the IWF Service Interface must meet JT-G.703a for J2 circuits. 

(R-15) Wander must meet JT-G.703a for J2 circuits. 

ANSI Tl.403-1995 specifies that wander shall not exceed 28 UI (18 jisec) peak-to-peak in 
any 24-hour period. Recommendations G.823 and G.824 require that network wander be 
maintained at less than 10 (isec over any 10 000 second interval (approximately 3 hours). 

2.1.5 Facility Data Link 

This section applies only to DS1 ESF Nx64 service and J2 Nx64 service. 

The DS1 ESF Facility Data Link associated with the Service Interface is terminated at the 
ESF/G.704 sublayer in the Interworking Function. 

The DS1 ESF Facility Data Link is used to carry once-per-second Performance Report 
Messages as described in T 1.403. These messages carry information on numbers of CRCs, 
framing errors, line code violations and other impairments detected over the last second. 

(CR-1) For DS1, the CES IWF shall terminate the Facility Data Link as specified in ANSI 
Tl.403-1995. 

(CR-2) DS1 Performance-related information from T 1.403 -compliant FDL messages shall 
be stored in the IWF's MIB, as described in Section 8. 

DS1 ESF FDL messages which are not Link Management messages as defined in Tl .403 
may be ignored by the IWF. 

The J2 Facility Data Link associated with the Service Interface is terminated at the J2/JT- 
G.704 sublayer in the Interworking Function. 

(CR-3) For J2, the CES IWF shall terminate the Facility Data Link as specified in JT- 
G.704. 

(CR-4) J2 Performance-related information from JT-G.704-compliant FDL messages shall 
be stored in the IWF's MIB, as described in Section 8. 

J2 FDL messages which are not Link Management messages as defined in JT-G.704 may 
be ignored by the IWF. 
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2.1.6 Bit Oriented Messages 

This section applies only to DS1 Nx64 service. 

(R-16) For DS1 using ESF, the IWF must terminate Bit Oriented Messages for Yellow 
Alarms and loopback as described in T 1.403. 

Loopbacks are handled as described in TR-NWT-000170. 

2.1.7 Alarms 

Several kinds of alarms can be detected at the point where the Service Interface is received 
by the IWF. Definition of alarm states is given in T 1.403 for DS1, G.704 for El, and JT- 
G.704for J2. 

Some alarm situations require that an alarm condition detected at the point where the 
Service Interface is received by an IWF (the "Upstream IWF") be propagated downstream 
to the IWF responsible for reproducing the bit stream (the "Downstream IWF"). 

When alarms are detected by the Upstream IWF, a Trunk Conditioning procedure is used 
to signal these alarms to downstream DS1/E1/J2 equipment. In this case, the Upstream 
IWF continues to emit cells at the nominal rate, but sets the DS1/E1/J2 payload to an 
appropriate code to indicate Idle or Out-of-Service. Additionally, if signalling bits are 
being carried by the IWF, the Upstream IWF will insert appropriate signalling codes into 
the DS1/E1/J2 stream before AAL1 segmentation takes place. Trunk conditioning 
procedures are specified in Bellcore TR-NWT-000170 Issue 2, Section 2.5. 

This technique allows DS1/E1/J2 alarm conditions to be transferred through the emulated 
circuit environment without causing additional ATM Layer errors. 

(R-17) The IWF shall detect Loss of Signal (LOS), AIS or Yellow conditions, loss of 
frame synch, and loss of multiframe synch and report these conditions via the MIB. 
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(R-18) When LOS, Out-of-Frame or AIS occur, the IWF shall apply Trunk Conditioning 
in the downstream direction. Procedures for Trunk Conditioning are described in Bellcore 
TR-NWT-000170 Issue 2, Section 2.5. A Remote Alarm Indication (RAI, or 'yellow') 
shall be delivered in the upstream direction. Figure 2-4 illustrates alarm handling at the 
Service Interface. The exact maintenance actions required to be performed depend on the 
application and environment being served. 



Detect AIS, LOS or OOF 



DS1/E1 
orJ2 
Equip 
Of 



CES 
IWF 



X 

o 



Fault 

Detect 

Transmit 



Transmit trunk conditioning downstream 



ATM 
Network 









— ► 








DS1/E1 




CES 




orJ2 




IWF 




) 






Equip 



Transmit RAI upstream 



Figure 2-4: Nx64 Service Interface Fault Indication 

(R-19) When RAI is received at the Service Interface, the IWF shall apply trunk 
conditioning in the downstream direction only. 

As noted earlier, this revision of this CES document does not provide any specific support 
for CCS signalling systems. Consequently, this section does not address a reaction of a 
CES IWF to an incoming AIS signal when CCS signaling is used. It should be noted that 
the presence of the AIS signal will disrupt any CCS data link carried over that same link. 
This disruption will cause the signaling system which uses the CCS link to declare an 
alarm. In this case, no further conditioning is required. 

Similarly, a second alarming condition (in CCS systems) is not addressed by this 
document. The situation is if the VC which carries the CCS link is different than the VC 
which carries the DSOs controlled by that CCS link. There is currently no means of 
conveying an alarm on that VC which carries the DSOs to the CCS system. This is similar 
to failure case in TDM networking where only some of the DSOs fail. In TDM 
networking, this case is sometimes handled by network management actions and other 
times by DSO testing systems used just as calls are being established. But since this version 
of this document does not specify support for CCS signalling systems, this situation is left 
for further study. 



2.1.8 Signalling Bits 

The Nx64 service can support signalling in one of two modes of operation: with Channel 
Associated Signalling (CAS) or without CAS. Nx64 Service with CAS requires direct 
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recognition and manipulation of the signalling bits by the CES IWF. This mode is 
necessary to support Nx64 applications requiring DS1 Robbed Bit Signalling or El CAS 
support. 

Conversely, non-CAS mode, or Basic Service, requires no direct CAS support by the CES 
IWF. Basic Service can be used to support Nx64 applications not requiring signalling or 
those that provide signalling using Common Channel Signalling (e.g., as used in N-ISDN) 
or provided by other means. 

(R-20) All Nx64 Service IWFs shall provide Basic Service. This mode is compatible with 
N-ISDN applications, as well as many video codecs. 

(0-3) Nx64 Service IWFs may also provide Nx64 Service with CAS. This mode is 
required for much existing PBX and voice telephony equipment. 

2.1.9 Service Performance Characteristics 

This section describes the minimal service performance characteristics required by Nx64 
Service. 

2.1.9.1 End-to-End Delay 

End-to-end delay requirements are application-specific. End-to-end delay requirements are 
beyond the scope of this specification. ITU-T Recommendation G.l 14 provides 
considerable guidance on the subject of delay. 

2.1.9.2 Error Ratios 

Bit Error Ratio (BER) is the ratio of the number of bit errors to the total number of bits 
transmitted in a given time interval. There are no specific bit-error ratio requirements for 
Nx64 service other than those implied by the errored second and severely-errored second 
requirements that follow. (Source: ANSI T 1.5 10- 1994, Network Performance Parameters 
for Dedicated Digital Services — Specifications.) 

Service performance is also measured in terms of Errored Seconds (ES) and Severely 
Errored Seconds (SES). Performance objectives for Errored Seconds and Severely Errored 
Seconds are given in ANSI Tl.510-1994 for DS1, and in G.826 for El. 

2.1.10 Electrical 

(R-21) The DS1 Nx64 Service shall provide a DSX-1 electrical interface with B8ZS 
coding. 

(0-4) The DS 1 Nx64 Service may also provide AMI coding as an option. 

The Service Interface may use a connector such as the RJ48C or RJ48M, as specified in 
T1.403. 

(R-22) The El Nx64 Service shall provide a G.703 interface using HDB3 line coding. 
G.703 allows both 75 Ohm and 120 Ohm interfaces for El. 
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The El Service Interface may use a connector such as IS08877 for the 120 Ohm interface, 
and a 75 Ohm BNC connector, as described in IECSC46D, for the 75 Ohm interface. 

(R-23) The J2 Nx64 Service shall provide a JT-G.703a interface with B8ZS coding. 

The J2 Service Interface shall use a 50 Ohm JIS C5412-1976 compliant connector as 
specified in JT-G.703a. 

2.2 AAL 1 Requirements 

2.2.1 Data Transfer Service Type 

(R-24) The Nx64 Service shall use the Structured Data Transfer (SDT) mode as defined in 
1.363.1. 

ANSI document Tl .630 and Bellcore GR-1 1 13-CORE also contain descriptions of AAL1 
Structured Data Transfer mode. 

2.2.2 Cell Utilization 

A significant source of delay in the Nx64 Service is the "cell payload assembly delay", or 
the amount of time it takes to collect enough data to fill a cell. This period of time can be 
reduced by sending cells that are only partially full, rather than waiting for a full 46- or 47- 
byte payload before sending each cell. This reduces delay at the expense of a higher cell 
rate. Partial cell fill is an optional feature of a CES IWF; if available, the number of bytes 
to be sent in each cell can be set when the virtual channel is established, either through 
configuration for PVCs, or by ATM UNI 3.1 signalling for SVCs. 

(R-25) The Nx64 Service Interworking Function shall be capable of sending cells without 
dummy octets. 

(O-S) The Nx64 Service may reduce cell payload assembly delay by introducing dummy 
octets to complete the cell payload, as outlined in ITU 1.363.1, 1996. 

It should be noted that the cell padding technique described in 1.363.1 requires a fixed 
number of payload (i.e., Service Interface) octets per cell, resulting in a variable number of 
pad bytes per cell, depending on the presence of the AAL1 Structure Pointer. 

When padding is used with Structured Data Transfer, it should be noted that 1.363. 1 
requires that the structure pointer span both payload and pad bytes. For example, a 
structure pointer with the value 46 always indicates the first octet of the second cell in a 
pair, no matter how much padding might be present in each cell. 
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2.3 AAL User Entity Requirements 
2.3.1 Cell Coding 

AAL1 as specified in ITU-T document 1.363.1 has the capability to delineate repetitive, 
fixed-size "blocks" of data, each block being an integral number of octets in size. This 
capability is used in the Nx64 service to carry N DSO timeslots, organized into blocks. 

For a block size of one octet, corresponding to a single DSO stream (i.e. N=l) with Basic 
Service, AAL1 provides block delineation merely by aligning each AAL user octet with an 
ATM cell payload octet. 

For a block size greater than one octet, AAL1 uses a pointer mechanism to indicate the 
start of a structure block. This AAL type 1 CS specification requires the pointer to be 
inserted at the first opportunity in a cell with an even sequence count value (i.e., 0, 2, 4, 6) 
as indicated by the CSI bit of the AAL1 header being set to "1". The SDT pointer must be 
inserted in a cell payload with an even sequence count once and only once in each set of 
eight cell payloads corresponding to an AAL1 sequence count cycle (i.e., 0,1,2,3,4,5,6,7). 
If no structure block begins with an eight cell sequence, then a pointer value of 127 shall 
be inserted in cell number six of the cycle. For more on Structured Data Transfer pointer 
generation and processing, refer to ITU Recommendation 1.363.1. 

The layout of the Nx64 service data within the structure blocks — or cell coding — varies 
with the type of Nx64 Service being supported, as described below. 

Logical Nx64 Service may use any of the coding approaches described below. 

Note: the need for a common method to transport CAS signaling transitions for DS1, El, 
J2 and voice compression is for further study. 

2.3.1.1 Cell Coding for DS1, El and J2 Nx64 Basic Service 

To encode Nx64 into AAL1 SDT without carrying signalling bits, a block is created by 
collecting N octets — one from each of the N timeslots to be carried — and grouping them 
in sequence. See Figure 2-5 for an example which shows the block structure for Nx64 
where N=3. The block size for Nx64 Basic mode is always N octets. 



Octet from first timeslot in current frame. 
Octet from second timeslot in current frame. 
Octet from third timeslot in current frame. 



Figure 2-5: Example Singleframe Structure Format for 3x64 kbit/s 

(R-26) DS1, El and J2 Nx64 Basic Service shall encode Nx64 Service data in an AAL1 
Structure of size *N\ 



AAL1 

Pointer 
► 
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2.3.1.2 Cell Coding for DS1, El and J2 Nx64 with CAS 

Circuits which carry the ABCD signalling bits end-to-end may also be emulated with the 
CES IWF, if the CAS mode option is provided. 

A special AAL1 structure format is used to carry emulated circuits with CAS. In this 
format, the AAL1 block is divided into two sections, the first of which carries the Nx64 
payload, the second of which carries signalling bits that are associated with the payload. 

In CAS Mode, the payload part of the structure is one multiframe in length. For Nx64 DS1 
with ESF framing, this portion of the AAL1 structure is N times 24 in length. For Nx64 El 
using G.704 framing, the payload portion of the AAL1 structure, called the Payload 
Substructure, is N times 16 octets in length. For Nx64 J2 using JT-G.704 framing and 
signalling, the payload portion of the AAL1 structure is N times 8 octets in length. In each 
case, the first octet in the AAL1 structure is from the first of the N timeslots in the first 
frame of a multiframe. 

The second portion of the AAL1 structure, called the Signalling Substructure, contains the 
signalling bits that are associated with the multiframe. For DS1 and El, the ABCD 
signalling bits associated with each time slot are packed two sets to an octet and placed at 
the end of the AAL1 structure. If N is odd, the last octet will contain only four signalling 
bits and four zero pad bits. For J2, which utilizes a single signalling bit per channel, the 
signalling bits associated with each timeslot are packed eight sets to an octet and placed at 
the end of the AAL1 structure. If N is not a multiple of 8, the last octet will contain only 
the remaining number of signalling bits and the rest of the octet will be padded with zero 
bits. 

The AAL1 Structure Pointer is used to indicate the first octet of the Payload Substructure. 
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An example of the AAL1 structure for DS1/E1 Nx64 circuits with CAS is shown in Figure 
2-6. In this example, N is set to three, so each AAL1 block contains payload from three 
timeslots, plus the three sets of signalling bits present in one multiframe. 



AAL1 
Pointer 



ABCD for 
first transported 
timeslot 



ABCD for 
third transported 
timeslot 




First transported octet of multiframe 
Second transported octet of multiframe 



First 125 usee frame of multiframe 



Second 125 usee frame of multiframe 



Last 125 usee frame of multiframe 



Signalling Substructure 



ABCD for 
second transported 
timeslot 



Figure 2-6: Example Multiframe Structure for 3x64 kbit/s DS1/E1 with CAS 
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An example of the AAL1 structure for J2 Nx64 circuits with CAS is shown in Figure 2-7. 
In this example, N is set to three, so each AAL1 block contains payload from three 
timeslots, plus the three sets of signalling bits present in one multiframe. 
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Signalling bit for 
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Signalling bi^ibr 
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Signalling bit for 
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Figure 2-7: Example Multiframe Structure for 3x64 kbit/s J2 with CAS 



Packing of the signalling bits for DS1 and El is done by using bits 8. .5 of the first octet for 
the first set of signalling bits, bits 4..1 of the first octet for the second set of signalling bits, 
and so on. Bits 4..1 of the last octet of the Signalling Substructure will be unused and shall 
be set to zero if the VCC is configured to carry an odd number of timeslots. Figure 2-8 
shows the assignment of bits to the signalling substructure. 
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Figure 2-8: Example DS1/ESF and El Signalling Substructure 
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Packing of the signalling bits for J2 is done by using the first bit (bit 8) of the first octet for 
the first channel's signalling bit, the second bit (bit 7) of the first octet for the second 
channel's signalling bit, and so on. Any unused bits of the last octet, when the number of 
channels is not an exact multiple of eight, shall be set to zero. Figure 2-9 shows the 
assignment of bits to the signalling substructure for J2. 
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Figure 2-9: Example J2 Signalling Substructure 



DS1 with Superframe Format (SF) can also be carried with a CES IWF. For SF format, 
the AAL1 structure is made the same size as the equivalent ESF structure by sending two 
SF multiframes together in one AAL1 block, instead of one multiframe as is done in ESF 
framing. For SF format, the signalling octets at the end of the AAL1 structure contain AB 
signalling bits from the two SF multiframes in the structure. Figure 2-10 shows the 
signalling substructure detail for an example circuit of N=3. In this example, signalling bits 
AB are from the first SF multiframe in the AAL1 structure, while bits A'B' are from the 
second SF multiframe. 
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Figure 2-10: Example DS1/SF Signalling Substructure 



Table 2-1 gives the size of the AAL1 structure in octets for a few different values of N. 
The parameter N gives the number of 64 kbit/s timeslots derived from a single access line 
to be transmitted over one VCC. A value of N = 1 corresponds to a single 64 kbit/s circuit; 
N = 6 corresponds to 384 kbit/s; N =30 corresponds to the full El payload of 1 .920 Mbit/s. 
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Framing 


Structure Size in Octets 

N=l N = 6 N = 24 N = 30 N = 96 


DS1/ESF 


25 


147 


588 


n/a 


n/a 


DS1/SF 


25 


147 


588 


n/a 


n/a 


El 


17 


99 


396 


495 


n/a 


J2 


9 


49 


195 


244 


780 



Table 2-1: Sample AAL1 Structure Sizes for Nx64 Service with CAS 

It should be noted, that in the case of DS1 with CAS, the ABCD bits may be present in the 
Payload Substructure in addition to being in the Signalling Substructure. In both 
circumstances of both normal operation, and also alarm conditions such as trunk 
conditioning, valid signalling must be sent in the Signalling substructure. 

(CR-5) If CAS mode operation is enabled for DS1, the Downstream IWF may only obtain 
ABCD signalling bits from the signalling substructure. 
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2.3.2 Bit Ordering 

Bits from the DS1, El or J2 Nx64 Service Interface are packed into ATM cells using the 
ordering shown in Figure 2-1 1. Note that G.704 and T 1.403 designate the most significant 
bit as 'bit 1 while ATM cells as defined in T 1.627 number the least significant bit as 'bit 
1\ In both cases, however, the most significant bit is transmitted first. , 
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F bl 
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time slot 2 




time slot 3 ... 



DS1/E1/J2 Bit Stream 




ATM 
Header 



cell 

payload 
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Figure 2-11: DS1/E1/J2 vs. ATM Bit Ordering 



2.3.3 Loss/Error Response 

The IWF will contain a function that reassembles a sequence of AAL1 cells into streams of 
octets for transmission by the DS1/E1/J2 Service Interface. This reassembly function must 
cope with a variety of errors and impairments, including lost cells, late cells and 
misinserted cells. 



2.3.3.1 Lost and Misinserted Cells 

The reassembly unit may detect lost and misinserted cells by processing sequence numbers 
in the AAL1 headers. 

(R-27) If cell loss is detected, dummy cells consisting of 46 or 47 octets shall be inserted 
when bit count integrity can be maintained. The content of the inserted octets is 
implementation-dependent. 

Depending on implementation, there will be a point at which too many cells will have been 
lost to maintain bit count integrity; at this point, the AAL1 receiver may have to locate the 
next AAL1 Structure Pointer to re-acquire framing. 

(0-6) Misinserted cells are expected to be rare. The reassembly unit may maintain bit 
count integrity where possible by dropping cells that the AAL1 header processor detects as 
misinserted. 
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2.3,3,2 Buffer Overflow/Underflow 

The reassembly function will require a buffer in which the reassembled cell stream is 
stored before it is transmitted out the Service Interface. The size of this buffer will be 
implementation dependent, but it must be large enough to accommodate expected CDV, 
while small enough to not introduce excessive delay in the emulated circuit. This buffer 
will be subject to overflow or underflow if slight clocking differences exist between the 
node at which segmentation takes place, and the node at which reassembly takes place. 
Buffer underflow may also result from unexpectedly large CDV. 

(R-28) The Nx64 Service IWF shall perform controlled frame slips if the reassembly 
buffer encounters an overflow or underflow (i.e., "starvation") condition. The data inserted 
in case of underflow is implementation-dependent. 

Under some circumstances, such as a failure in the ATM network carrying the emulated 
Nx64 circuit, the flow of cells to the reassembly unit will stop for an extended period. This 
condition shall be signalled to the external equipment attached to the Service Interface by 
Trunk Conditioning, as illustrated in Figure 2-12. 



DS1/E1 
or J2 
Equip 

04 



X 

O 



Detect Loss of Cells 



Transmit trunk conditioning 
^/ downstream 



CES 
IWF 



ATM 
Network 



X-fo O 



CES 
IWF 



DS1/E1 
or J2 
Equip 



Fault 

Detect 

Transmit 



Transmit trunk conditioning 
upstream 



Figure 2-12: Virtual Channel Fault Indication 

(R-29) After an integration period, a persistent buffer starvation condition shall trigger 
Trunk Conditioning, as specified in Bellcore TR-NWT-000170. 

The length of the integration period has not yet been specified by ITU-T, ANSI and/or 
ETSI. Pending specification, implementors are advised to use a 2.5 +/- 0.5 second 
integration period, in a manner analogous to that used to integrate Loss of Signal to declare 
red alarm state. 

Although not required as part of this specification, implementors may wish to consult 
Bellcore GR-1 1 13-CORE and ETSI ETS 300 353 Annex D for advice on the handling of 
various fault conditions. 
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2.4 Clock Distribution Guidelines 

As stated in Section 2.1.3, IWFs which support network-synchronous services must 
provide a means by which a timesource traceable to a Primary Reference Source (PRS) 
may be supplied. For DS1, El and J2 Nx64 Service, the IWF must provide timing at the 
DS1/E1/J2 Service Interface. 

While the technique by which that clock is provided at the Service Interface is beyond the 
scope of this specification, here are some possible techniques: 

1 . A PRS-traceable source is used to time the physical layers 
supporting ATM links between the IWF and the ATM network. 
Timing might be introduced to the ATM network via a Central 
Office Clock connection on one or more ATM switches. Each CES 
IWF receives timing from its ATM interface. 

2. The physical links accessing an ATM network might be 
synchronized to a PRS as above, but the timing might be introduced 
to the ATM network via a DS1/E1/J2 interface. 

3. Not all IWF access interfaces may convey timing which is PRS- 
traceable. If the CES IWF access interface does not convey PRS- 
traceable timing, then PRS-traceable timing must be externally 
supplied to the external equipment. 

4. In some private network applications involving circuit emulation, it 
may be sufficient to distribute a common clock to all CES IWF 
nodes, but not require that the common clock be traceable to a 
Stratum 1 oscillator. Note, however, that the use of synchronization 
timing below PRS could result in internetworking difficulties 
between different network domains, such as interconnection 
involving multiple public network providers. ANSI T1X1.3 is 
currently studying these types of issues. 

In all cases, Service Interfaces are expected to be timed from a single, common clock, or 
one or more PRSs. Service Interface timing is not carried across the network via SRTS, or 
through the use of Adaptive clock recovery. All Nx64 emulated circuits are carried with 
AAL1 Synchronous mode, as described in Tl .630. 

Information on the distribution of network timing may be found in ANSI T1.101 and in 
ISO/IEC 11573. 
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3. DS1/E1/J2 Unstructured Service 

A large number of applications utilize DS1, El and J2 interfaces today, making use of the 
entire bandwidth. Within this section, the following conventions apply: 

Unstructured Service = All modes of the unstructured DS1/E1 and J2 Unstructured 
Service. 

DS1 Unstructured Service = Unstructured Service at a nominal bit rate of 1.544 Mb/s in 
which the two IWFs involved are emulating a DS1 circuit supplied via a DSX-1 interface. 

El Unstructured Service = Unstructured Service at a nominal bit rate of 2.048 Mb/s in 
which the two IWFs involved are emulating an El circuit supplied via a G.703 interface. 

J2 Unstructured Service = Unstructured Service at a nominal bit rate of 6.312 Mb/s in 
which the two IWFs involved are emulating a J2 circuit supplied via a JT-G.703a interface. 

DS1 Logical Unstructured Service = Unstructured Service at a nominal bit rate of 1.544 
Mb/s in which the non-ATM-related functions of the two IWFs involved are left 
unspecified. 

El Logical Unstructured Service = Unstructured Service at a nominal bit rate of 2.048 
Mb/s in which the non- ATM-related functions of the two IWFs involved are left 
unspecified. 

J2 Logical Unstructured Service = Unstructured Service at a nominal bit rate of 6.3 12 Mb/s 
in which the non-ATM-related functions of the two IWFs involved are left unspecified. 

3.1 Service Description 

DS1/E1/J2 Unstructured CBR service is intended to emulate a point-to-point DS1, El or J2 
circuit. The service is accessed via either a 1.544 Mbit/s DSX-1 interface, a 2.048 Mbit/s 
G.703 interface or a 6.312 Mbit/s JT-G.703a interface. The service is defined as a "clear 
channel pipe", transparently carrying any arbitrary 1 .544 Mbit/ s (2.048 Mbit/s for El and 
6.312 Mbit/s for J2) data stream. The end-user timing source for these interface signals is 
not necessarily traceable to a PRS. 

Note that framing formats other than standard SF, ESF, G.704 or JT-G.704 formats cannot 
be supported by all PDH/SDH installed equipment. If CES service for such non-standard 
framing formats is offered by an exchange carrier, the carrier may have difficulty in 
maintaining the service interface due to the lack of facility support for operations and 
maintenance functions such as performance monitoring, facility loopbacks and so forth. 

The DS1/E1/J2 Unstructured Service also provides an optional feature that allows non- 
intrusive performance monitoring of the link if SF, ESF, G.704 or JT-G.704 framing is 
used. 

Figure 3-1 shows the DS1/E1/J2 Unstructured Service from a layering perspective. For this 
service, the CES interworking function has two physical layers, one for the CBR circuit to 
be emulated and one for ATM. Linking the CBR physical layer with the AAL1 layer is a 
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"mapping function". In Unstructured service, the mapping function simply maps every bit 
between the AAL1 layer and the 1.544, 2.048 or 6.312 Mbit/s Service Interface. From an 
ATM perspective, everything shaded in the diagram represents an "AAL User Entity," and 
that is how we refer to the shaded portions in the CES-IS. For the "logical" versions of the 
Circuit Emulation Services, the CES-IS leaves the non-ATM portions identified in the 
figure (i.e., the CBR Physical layer and CBR Service Interface) unspecified. 
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Figure 3-1: DS1/E1/J2 Unstructured Service Interworking Function - Layering 

Perspective 



3.1.1 Framing 

(R-30) The DS1/E1/J2 Unstructured Service carries any arbitrary 1.544 Mbit/s (2.048 
Mbit/s for El and 6.312 Mbit/s for J2) data stream. 

(0-7) Optionally, the Unstructured service may include a non-intrusive performance 
monitoring function that will decode but not terminate SF, ESF, G.704 or JT-G.704 
framing. The functions required to support this option are: collection of performance 
statistics, and detection of frame-based alarms and messages. There must be a 
configuration option to disable the performance monitor for use with unframed signals. 

3.1.2 Clocking 

The DS1/E1/J2 Unstructured Service has two modes for timing user equipment attached to 
the Service Interface: 

1. Synchronous Mode, in which timing is supplied to attached 

DS1/E1/J2 equipment via the IWF Service Interface, and may be 
traceable to a Primary Reference Source. 
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2. Asynchronous Mode, in which timing is supplied by an independent 
clock in the attached equipment and carried transparently through 
the ATM network. 

When asynchronous timing is supplied by the attached equipment, the end-user timing 
source for this asynchronous timing may or may not be traceable to a PRS. Whether or not 
an interface signal is traceable to a PRS impacts the choice of clock recovery method. If 
asynchronous CES service is being provided to a CBR interface which does not use timing 
traceable to a PRS, then SRTS may not be supportable. In order to support SRTS 
application when the CES IWF does not use timing traceable to a PRS, the CES IWF must 
have available for its use a reference clock which is common to the reference clock being 
used by the CES IWF at the other end of the connection. 

(R-31) A CES IWF must implement at least one of the two clocking modes for DS1/E1/J2 
Unstructured Service, and may offer both modes. Two Interworking Functions must be 
configured for the same clocking mode in order to interoperate. 

(CR-6) If Asynchronous Mode is used, timing shall be properly accepted from user 
equipment as long as that timing is within +/-130 ppm for DS1 (as specified in T 1.403- 
1995), +/- 50 ppm for El (as specified in G.703) and +/- 30 ppm for J2 (as specified in JT- 
G.703a). Note that the 130 ppm tolerance for DS1 is intended to support older DS1 
equipment. Newer equipment will be within +/- 32 ppm. 

3.1.3 Jitter and Wander 

Jitter and Wander may be present at the output of the emulated circuit, introduced, for 
example, by imperfections in clock recovery at the output of the CES IWF. For circuits 
using the Asynchronous timing mode, there are two techniques for recovering clock — 
SRTS and Adaptive (see Section 3.4). While the two techniques can produce equal jitter 
performance, they may differ in the amount of wander present at the output of the IWF. 

Wander requirements apply to network-synchronous signals (i.e., those traceable to a PRS) 
but the same requirements may be applied to an asynchronous signal if the wander is 
defined as relative to the clock source rather than to an absolute reference. ANSI technical 
sub-committee T1E1, the group responsible for T 1.403 and T 1.404, is studying this area 
with input from T1X1.3. 

(R-32) Jitter measured at the output of the IWF Service Interface and tolerated at the input 
of the IWF Service Interface shall meet ANSI T1.102 and G.824 for DS1 circuits with any 
clocking mode. 

(R-33) Jitter measured at the output of the IWF Service Interface and tolerated at the input 
of the IWF Service Interface shall meet G.823 for El circuits with any clocking mode. 

(R-34) Jitter measured at the output of the IWF Service Interface and tolerated at the input 
of the IWF Service Interface must meet JT-G.703a for J2 interfaces with any clocking 
mode. 

(CR-7) If Synchronous clocking or Asynchronous clocking with SRTS clock recovery is 
used, wander must meet ANSI Tl .403 and G.824 for DS1 circuits. 
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(CR-8) If Synchronous clocking or Asynchronous clocking with SRTS clock recovery is 
used, wander must meet G.823 for El circuits. 

(CR-9) If Synchronous clocking or Asynchronous clocking with SRTS clock recovery is 
used, wander must meet JT-G.703a for J2 circuits. 

ANSI Tl.403-1995 5.7.5 specifies that wander shall not exceed 28 UI (18 |Usec) peak-to- 
peak in any 24-hour period. Recommendations G.823 and G.824 suggest that network 
wander be maintained at less than 10 |isec over any 10,000 second interval (approximately 
3 hours). 

If the Asynchronous clocking mode is used with Adaptive clock recovery, the resulting 
wander will depend on the CDV characteristics of the ATM network used to interconnect 
Interworking Functions, and might not meet recommendations specified in T1.403, G.823 
or G.824. 

Note: for circuit emulation service, ITU-T Recommendation 1.363.1 and ANSI T1.630 
specify the SRTS method of timing recovery to guarantee/meet performance requirements 
(jitter and wander) of G.823 and G.824. If either IWF connects to DS1, El or J2 
equipment in the public network, the Public Network Operator may require that SRTS be 
used. 

3.1.4 Facility Data Link 

The Unstructured Circuit Emulation Service will carry any signal that meets the bit rate 
requirement specified in Section 3.1.2, without regard to framing. In the particular case of 
DS1 circuits using ESF framing, a Facility Data Link (FDL) may be present in the signal. 
If this is the case, the CES IWF is allowed to monitor the FDL, but must not change 
messages carried by the FDL, or insert new FDL messages. 

(R-35) The Facility Data Link associated with the Service Interface, if present, shall not be 
modified by the Unstructured Service Interface. 

(CR-10) If the optional performance monitoring feature is enabled, the Interworking 
Function shall monitor Performance Report Messages as described in Tl .403. The 
collected statistics shall be stored in the MIB, as described in Section 8. 

3.1.5 Alarms 

(R-36) For DS1, El or J2 Unstructured Service, all alarms received at the input of the 
Service Interface are carried through to the output Service Interface without modification. 
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(R-37) The IWF shall detect Loss of Signal at the IWF Service Interface. Upon detection 
of LOS, the segmenting IWF shall send cells containing all-ones, effectively propagating 
an unframed AIS signal. This situation is illustrated in Figure 3-2. 
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Figure 3-2: Unstructured DS1/E1/J2 Service Interface Fault Indication 

(CR-11) If the optional performance monitoring feature is provided for the DS1, El or J2 
Unstructured Service, the CES Interworking Function shall monitor the alarm status of the 
Service Interface. Alarm status shall be reflected in the MIB. 

3.1.6 Service Performance Characteristics 

This section describes the minimal service performance characteristics required by the 
Unstructured Service. 

3.1.6.1 End-to-End Delay 

End-to-end delay requirements are application-specific. End-to-end delay requirements are 
beyond the scope of this specification. 



3.1.6.2 Error Ratios 

BER is the ratio of the number of bit errors to the total number of bits transmitted in a 
given time interval There are no specific bit-error ratio requirements for DS1/E1/J2 CBR 
service other than those implied by the errored second and severely-errored second 
requirements that follow. (Source: ANSI T 1.5 10- 199 1 4, Network Performance Parameters 
for Dedicated Digital Services — Specifications,) 

Service performance is also measured in terms of Errored Seconds (ES) and Severely 
Errored Seconds (SES). Performance objectives for Errored Seconds and Severely Errored 
Seconds are given in ANSI TL510-1994. 
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3,1.7 Electrical 

(R-38) For the DS1 Unstructured Service, the Service Interface will provide a DSX-1 
electrical interface with B8ZS coding. 

(0-8) For the DS1 Unstructured Service, AMI coding may be provided as an option. 

The Service Interface may use a connector such as the RJ48C or RJ48M, as specified in 
T1.403. 

(R-39) For the El Unstructured Service, the Service Interface will provide a G.703 
interface using HDB3 line coding. G.703 allows both 75 Ohm and 120 Ohm interfaces for 
El. 

The El Service Interface may use a connector such as IS08877 for the 120 Ohm interface, 
and a 75 Ohm BNC connector, as described in IECSC46D, for the 75 Ohm interface. 

(R-40) For the J2 Unstructured Service, the Service Interface will provide a JT-G.703a 
interface using B8ZS coding. 

The J2 Service Interface shall use a 50 Ohm JIS C5412-1976 compliant connector as 
specified in JT-G.703a. 

3.2 AAL 1 Requirements 

3.2.1 Data Transfer Service Type 

(R-41) The Unstructured service shall use the Unstructured Data Transfer (UDT) mode as 
defined in T1.630 and 1.363.1. 

3.2.2 Cell Utilization 

(R-42) In accordance with ANSI T 1.630, the IWF shall fill the entire 47-octet cell payload 
with DS1/E1/J2 data. 

3.3 AAL User Entity Requirements 
3.3.1 Cell Coding 

Unstructured Data Transfer does not rely on any particular data format. Bits received from 
the service interface are packed into cells without regard to framing. Note that no particular 
alignment between octets in DS1, El and J2 frames and octets in an ATM cell can be 
assumed with Unstructured Data Transfer. 

However, correct bit ordering must be used. Considering the 376 contiguous bits that will 
be packed into the SDU, the first bit received on the DS1/E1/J2 line is placed in the MSB 
of the first octet of the SDU, and placement proceeds in order until the last bit is placed in 

the LSB of the 47 th octet of the SDU. 
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3.3.2 Loss/Error Response 

The IWF should attempt to maintain "bit count integrity"; i.e., the number of DS1/E1/J2 
bits coming into the segmenting IWF providing the Unstructured service should equal the 
number of DS1/E1 bits leaving the reassembling IWF whenever possible. Failure to 
maintain bit count integrity will probably cause end-user equipment to suffer a reframe 
event. 

3.3.2.1 Lost and Misinserted Cells 

The reassembly unit may detect lost and misinserted cells by processing sequence numbers 
in the AAL1 headers. 

(R-43) If lost cells are detected, dummy cells consisting of 47 octets of all ones shall be 
inserted when bit count integrity can be maintained. In order to also maintain bit sequence 
integrity, these data bits from the dummy pay loads must be positioned in place of the bits 
lost in the missing cell payloads. Depending on implementation, there will be a point at 
which too many cells will have been lost to maintain bit count integrity. 

(0-9) The reassembly unit may maintain bit count integrity where possible by dropping 
cells that the AAL1 header processor detects as misinserted. 

3.3.2.2 Buffer Overflow/Underflow 

The reassembly function will require a buffer in which the reassembled cell stream is 
stored before it is transmitted out the Service Interface. The size of this buffer will be 
implementation dependent, but it must be large enough to accommodate expected CDV, 
while small enough to not introduce excessive delay in the emulated circuit. This buffer 
will be subject to overflow or underflow if slight clocking differences exist between the 
node at which segmentation takes place, and the node at which reassembly takes place. 
Buffer underflow may also result from unexpectedly large CDV. 

(R-44) The IWF shall insert an all-ones pattern if the reassembly buffer encounters an 
underflow (i.e., "starvation") condition. This condition may result in a reframe event for 
DS1/E1 or J2 equipment using the Unstructured service. 

Under some circumstances, such as a failure in the ATM network carrying the emulated 
circuit, the flow of cells to the reassembly unit will stop for an extended period. The Loss- 
of-Cells condition should be signalled to the downstream external equipment attached to 
the Service Interface by sending the all-ones AIS pattern, as illustrated in Figure 3-3. 
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Figure 3-3: Virtual Channel Fault Indication 

(R-45) After an integration period, a persistent buffer starvation condition shall trigger a 
Loss-of-Cells fault indication, resulting in downstream AIS. 

The length of the integration period has not yet been specified by ITU-T, ANSI and/or 
ETSI. Pending specification, implementors are advised to use a 2.5 +/- 0.5 second 
integration period, in a manner analogous to that used to integrate Loss of Signal to declare 
red alarm state. 

The reassembly buffer can also suffer an overflow condition due to a clocking error. In this 
case, the IWF shall drop a number of bits from the reassembled stream. The number of bits 
dropped at each buffer overflow event is implementation dependent. A buffer overflow is 
likely to result in a reframe event for DSl/El or J2 equipment using the Unstructured 
service. 

(R-46) The IWF shall drop an implementation-dependent number of bits in case of a buffer 
overflow. 

Although not required as part of this specification, implementors may wish to consult 
Bellcore GR-1 1 13-CORE and ETSI ETS 300 353 Annex D for advice on the handling of 
various fault conditions. 



3.4 Clock Recovery 

The Unstructured service may carry network-synchronous (i.e., traceable to a PRS) or 
asynchronous DS1, El or J2 circuits. In an asynchronous situation, the input Service clock 
frequency must be recovered at the output IWF. There are two techniques for recovering 
this clock, Synchronous Residual Time Stamp (SRTS) and Adaptive. Either technique may 
be used, although SRTS may give better control over wander introduced into the emulated 
circuit, depending on the wander generation mechanisms. 
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For circuit emulation of both network-synchronous and asynchronous signals, the SRTS 
clock recovery technique requires a network reference clock (i.e., traceable to a PRS); - 
information on the distribution of network timing may be found in ANSI document T 1.101 
and in ISO/IEC 11573. 

3.4.1 SRTS 

The SRTS technique measures the Service Clock input frequency against a network-wide 
synchronization signal that must be present in the IWF, and sends difference signals, called 
Residual Time Stamps, in the AAL1 header to the reassembly IWF. At the output IWF, the 
differences can be combined with the network-wide synchronization signal, to re-create the 
input Service clock. Note that this network-wide synchronization signal must be traceable 
to a PRS. 

(CR-12) If SRTS is provided, it shall be used as specified in T 1.630 and 1.363.1. 

(CR-13) The network derived clock frequency (f ox ) used in the SRTS algorithm shall be 
2.43 MHz for both DS1 and El circuit emulation. 

(CR-14) The network derived clock frequency (f ox ) used in the SRTS algorithm shall be 
9.72 MHz for J2 circuit emulation. 

3.4.2 Adaptive 

The adaptive technique does not require a network-wide synchronization signal to 
regenerate the input Service clock at the output IWF. 

A variety of techniques could be used to implement Adaptive clock recovery. For example, 
the depth of the reassembly buffer in the output IWF could be monitored: 

1 . When the buffer depth is too great or tends to increase with time, 
the frequency of the Service clock could be increased to cause the 
buffer to drain more quickly. 

2. When the buffer contains fewer than the configured number of bits, 
the Service clock could be slowed to cause the buffer to drain less 
quickly. 

Wander may be introduced by the Adaptive clock recovery technique if there is a low- 
frequency component to the Cell Delay Variation inserted by the ATM network carrying 
cells from the input to output IWF. 
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4. Unstructured DS3/E3 Service 

Applications may utilize DS3/E3 interfaces today, either utilizing the entire bandwidth, or 
through the use of multiplexing performed in end systems. Within this section, the 
following conventions apply: 

Unstructured DS3/E3 Service = All modes of the Unstructured DS3/E3 Service. 

Unstructured DS3 Service = Unstructured DS3/E3 Service at a nominal bit rate of 44.736 
Mbit/s in which the two IWFs involved are emulating a DS3 circuit supplied via a DSX-3 
interface. 

Unstructured E3 Service = Unstructured DS3/E3 Service at a nominal bit rate of 34.368 
Mbit/s in which the two IWFs involved are emulating an E3 circuit supplied via a G.703 
interface. 

Logical Unstructured DS3 Service = Unstructured DS3/E3 Service at a nominal bit rate of 
44.736 Mbit/s in which the non-ATM-related functions of the two IWFs involved are left 
unspecified. 

Logical Unstructured E3 Service = Unstructured DS3/E3 Service at a nominal bit rate of 
34.368 Mbit/s in which the non-ATM-related functions of the two IWFs involved are left 
unspecified. 

4.1 Service Description 

Unstructured DS3/E3 Service is intended to emulate a point-to-point DS3 or E3 circuit. 
The service is accessed via either a 44.736 Mbit/s DSX-3 interface or a 34.368 Mbit/s 
G.703 interface. The service is defined as a "clear channel pipe", transparently carrying 
any arbitrary 44.736/34.368 Mbit/s data stream. The end-user timing source for these 
interface signals is not necessarily traceable to a PRS. 

Note that framing formats other than standard DS3 or E3 formats cannot be supported by 
all PDH/SDH installed equipment. If CES service for such non-standard framing formats is 
offered by an exchange carrier, the carrier may have difficulty in maintaining the service 
interface due to the lack of facility support for operations and maintenance functions such 
as performance monitoring, facility loopbacks and so forth. 
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Figure 4-1 shows the Unstructured DS3/E3 Service from a layering perspective. For this 
service, the CES interworking function has two physical layers, one for the CBR circuit to 
be emulated and one for ATM. Linking the CBR physical layer with the AAL1 layer is a 
"mapping function". In Unstructured DS3/E3 Service, the mapping function simply maps 
every bit between the AAL1 layer and the 44.736 or 34.368 Mbit/s Service Interface. From 
an ATM perspective, everything shaded in the diagram represents an "AAL User Entity," 
and that is how we refer to the shaded portions in the CES-IS. For the "logical" versions of 
the Circuit Emulation Service, the CES-IS leaves the non-ATM portions identified in the 
figure (i.e., the CBR Physical layer and CBR Service Interface) unspecified. 
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4.1.1 Framing 

(R-47) The Unstructured DS3/E3 Service shall carry any arbitrary 44.736/34.368 Mbit/s 
data stream. 

4.1.2 Clocking 

The Unstructured DS3/E3 Service has two modes for timing user equipment attached to 
the Service Interface: 

1) Synchronous Mode, in which timing is supplied to attached DS3/E3 equipment via 
the IWF Service Interface, and may be traceable to a Primary Reference Source. 

2) Asynchronous Mode, in which timing is supplied by attached equipment and 
carried through the ATM network. 
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When asynchronous timing is supplied by the attached equipment, the end-user timing 
source for this asynchronous timing may or may not be traceable to a PRS. Whether or not 
an interface signal is traceable to a PRS impacts the choice of clock recovery method. If 
asynchronous CES service is being provided to a CBR interface which is not traceable to a 
PRS, then SRTS may not be supportable. In order to support SRTS application when the 
CES IWF does not use timing traceable to a PRS, the CES IWF must have available for its 
use a reference clock which is common to the reference clock being used by the CES IWF 
at the other end of the connection. 

(R-48) A CES IWF must implement at least one of the two clocking modes for 
Unstructured DS3/E3 Service, and may offer both modes. Two Interworking Functions 
must be configured for the same clocking mode in order to interoperate. 

(CR-15) If Asynchronous Mode is used, timing shall be properly accepted from user 
equipment as long as that timing is within +/- 20 ppm (as specified in T 1.1 02 for DS3 and 
inG.703 forE3). 

4.1.3 Jitter and Wander 

Jitter and Wander may be present at the output of the emulated circuit, introduced, for 
example, by imperfections in clock recovery at the output of the CES IWF. For circuits 
using the Asynchronous timing mode, there are two techniques for recovering clock — 
SRTS and Adaptive (see Section 4.4). While the two techniques can produce equal jitter 
performance, they may differ in the amount of wander present at the output of the IWF. 

Wander requirements apply to network-synchronous signals (i.e., traceable to a PRS) but 
the same requirements may be applied to an asynchronous signal if the wander is defined 
as relative to the source clock rather than to an absolute reference. ANSI technical sub- 
committee T1E1, the group responsible for T 1.403 and T 1.404, is studying this area with 
input from T1X1.3. 

(R-49) Jitter measured at the output of the IWF Service Interface and tolerated at the input 
of the IWF Service Interface shall meet ANSI T 1.1 02 and ITU-T G.824 for DS3 circuits 
with any clocking mode. 

(R-50) Jitter measured at the output of the IWF Service Interface and tolerated at the input 
of the IWF Service Interface shall meet ITU-T G.823 for E3 circuits with any clocking 
mode. 

(CR-16) If Synchronous clocking or Asynchronous clocking with SRTS clock recovery is 
used, wander must meet T1.404 and G.824 for DS3 circuits. 

(CR-17) If Synchronous clocking or Asynchronous clocking with SRTS clock recovery is 
used, wander must meet G.823 for E3 circuits. 

If the Asynchronous clocking mode is used with Adaptive clock recovery, the resulting 
wander will depend upon the CDV characteristics of the ATM network used to 
interconnect Interworking Functions, and might not meet recommendations specified in 
G.823 or G.824. 
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Note: For Circuit Emulation Service, ITU-T Recommendation 1.363.1 and ANSI T1.630 
specify the SRTS method of timing recovery to guarantee/meet performance requirements 
(jitter and wander) of G.823 and G.824. If either IWF connects to DS3 or E3 equipment in 
the public network, the Public Network Operator may require that SRTS be used. 



4.1.4 Alarms 



(R-51) For Unstructured DS3/E3 Service, all alarms received at the input of the Service 
Interface are carried through to the output Service Interface without modification. 

(R-52) The IWF shall detect Loss of Signal (LOS) at the IWF Service Interface. Upon 
detection of LOS, the segmenting IWF shall send cells containing an AIS pattern (all-ones 
for E3, framed 1010.. for DS3 as specified in ANSI T1.107) downstream. This situation is 
illustrated in Figure 4-2. 
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Figure 4-2: Unstructured DS3/E3 Service Interface Fault Indication 



4.1.5 Service Performance Characteristics 

This section describes the minimal service performance characteristics required by the 
Unstructured DS3/E3 Service. 

4.1.5.1 End-to-End Delay 

End-to-end delay requirements are application specific. End-to-end delay requirements are 
beyond the scope of this specification. 

4.1.5.2 Error Ratios 

Bit Error Ratio (BER) is the ratio of the number of bit errors to the total number of bits 
transmitted in a given time interval. There are no specific bit-error ratio requirements for 
Structured DS3/E3 Service other than those implied by the errored second and severely- 
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errored second requirements identified in the following paragraph. (Source: ANSI T1.510- 
1 994, Network Performance Parameters for Dedicated Digital Services — Specifications.) 

Service performance is also measured in terms of Errored Seconds (ES) and Severely 
Errored Seconds (SES). Performance objectives for Errored Seconds and Severely Errored 
Seconds are given in ANSI Tl. 5 10- 1994 for DS3, and in G.826 for E3. 

4.1.6 Electrical 

(R-53) The Unstructured DS3 Service shall provide a 44.736 Mbit/s DSX-3 interface with 
B3ZS line coding, as specified in T 1.1 02. 

(R-54) The Unstructured E3 Service shall provide a 34.368 Mbit/s G.703 interface with 
HDB3 line coding. 

4.2 AAL1 Requirements 

4.2.1 Data Transfer Service Type 

(R-55) The Unstructured DS3/E3 Service shall use the Unstructured Data Transfer (UDT) 
mode as defined in 1.363.1 and T1.630. 

4.2.2 Cell Utilization 

(R-56) In accordance with ANSI T 1.630, the IWF shall fill the entire 47 octet cell payload 
with DS3/E3 data. 

4.3 AAL User Entity Requirements 

4.3.1 Cell Coding 

Unstructured Data Transfer does not rely on any particular data format. Bits received from 
the Service Interface are packed into cells without regard to framing. Note that no 
particular alignment between any octets in DS3 or E3 frames and octets in an ATM cell 
can be assumed with Unstructured Data Transfer. 

However, correct bit ordering must be used. Considering the 376 contiguous bits that will 
be packed into the AAL1 SDU (Service Data Unit), the first bit received on the DS3/E3 
line is placed in the MSB of the first octet of the SDU. Placement then proceeds in order 
until the last bit is placed in the LSB of the 47th octet of the SDU. 

4.3.2 Loss/Error Response 

The IWF should attempt to maintain "bit count integrity"; i.e., the number of DS3/E3 bits 
coming into the segmenting IWF providing the Unstructured DS3/E3 Service should equal 
the number of DS3/E3 bits leaving the reassembling IWF whenever possible. Failure to 
maintain bit count integrity will probably cause end-user equipment to suffer a reframe 
event. 
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4.3.2.1 Lost and Misinserted Cells 

The reassembly unit may detect lost and misinserted cells by processing sequence numbers 
in the AAL1 headers. 

(R-57) If cell loss is detected in Unstructured E3 Service, dummy cells consisting of 47 
octets of all ones shall be inserted in order to maintain bit count integrity. In order to also 
maintain bit sequence integrity, these data bits from the dummy payloads must be 
positioned in place of the bits lost in the missing cell payloads. Depending upon 
implementation, there will be a point at which too many cells will have been lost to be able 
to assure the maintenance of bit count integrity. 

(R-58) If cell loss is detected in Unstructured DS3 Service, dummy cells consisting of a 
framed DS3 AIS shall be inserted as specified by ANSI T 1.630. This framed DS3 AIS 
consists of a framed 1010.. bit sequence, as described in ANSI T1.404. In order to also 
maintain bit sequence integrity, these data bits from the dummy payloads must be 
positioned in place of the bits lost in the missing cell payloads. When multiple contiguous 
dummy cells must be inserted, the content of these cells shall form a continuous framed 
DS3 AIS, such that a continuous sequence of these cells would cause a continuous framed 
DS3 AIS to be reconstructed by the reassembly unit. The framed DS3 AIS content of these 
dummy cells need not be aligned with the original DS3 signal, however. Depending upon 
implementation, there will be a point at which too many cells will have been lost to be able 
to assure the maintenance of bit count integrity. However, as long as contiguous dummy 
cells must be inserted in order to maintain a reconstructed bit stream, the content of these 
inserted cells shall form the continuous framed DS3 AIS as specified by ANSI T 1.630. 

(O-10) Misinserted cells are expected to be rare. The reassembly unit may maintain bit 
count integrity where possible by dropping cells that the AAL1 header processor detects as 
misinserted. 

4.3.2.2 Buffer Overflow/Underflow 

The reassembly function will require a buffer in which the reassembled cell stream is 
stored before it is transmitted out the Service Interface. The size of this buffer will be 
implementation dependent, but it must be large enough to accommodate expected CDV, 
while small enough to not introduce excessive delay in the emulated circuit. This buffer 
will be subject to overflow or underflow if slight clocking differences exist between the 
node at which segmentation takes place and the node at which reassembly takes place. 
Buffer underflow/overflow may also result from unexpectedly large CDV. 

(R-59) An Unstructured E3 Service IWF shall insert an all-ones pattern if the reassembly 
buffer encounters an underflow (i.e., "starvation") condition. This condition may result in a 
reframe event for E3 equipment using this service. 

(R-60) An Unstructured DS3 Service IWF shall insert a framed DS3 AIS pattern if the 
reassembly buffer encounters an underflow (i.e., "starvation") condition. The inserted data 
shall form a continuous framed DS3 AIS pattern as long as contiguous data must be 
inserted. This pattern need not be aligned with the original DS3 signal, however. This 
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reassembly buffer underflow condition may result in a reframe event for DS3 equipment 
using this service. 

Under some circumstances, such as a failure in the ATM network carrying the emulated 
circuit, the flow of cells to the reassembly unit will stop for an extended period. This 
condition shall be signalled to the external equipment attached to the Service Interface by 
sending an AIS pattern (all ones for E3, framed 1010.. for DS3 as specified in ANSI 
Tl . 107) downstream, as illustrated in Figure 4-3 . 
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Figure 4-3: Unstructured DS3/E3 Virtual Channel Fault Indication 



(R-61) After an integration period, a persistent buffer starvation condition for an 
Unstructured E3 Service shall trigger generation of an AIS pattern (all ones) downstream. 

(R-62) After an integration period, a persistent buffer starvation condition for an 
Unstructured DS3 Service shall trigger the generation of a continuous framed DS3 AIS 
(framed 1010..) downstream. The framing of this DS3 AIS shall be a continuous extension 
of the framing of the DS3 AIS being inserted while the starvation condition was being 
integrated. 

The length of the integration period has not yet been specified by ITU-T, ANSI and/or 
ETSI. Pending specification, implementors are advised to use a 2.5 +/- 0.5 second cell loss 
integration period. 

The reassembly buffer can also suffer an overflow condition due to a clocking error. In this 
case, the IWF shall drop a number of bits from the reassembled stream. The number of bits 
dropped at each buffer overflow event is implementation dependent. A buffer overflow is 
likely to result in a reframe event for DS3/E3 equipment using the Unstructured DS3/E3 
Service. 

(R-63) The Unstructured DS3/E3 Service IWF shall drop an implementation dependent 
number of bits in case of a buffer overflow. 
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Although not required as part of this specification, implementors may wish to consult 
Bellcore GR-1 1 13-CORE and ETSI ETS 300 353 Annex D for advice on the handling of 
various fault conditions. 

4.4 Clock Recovery 

The Unstructured DS3/E3 Service may carry asynchronous DS3 or E3 circuits. In this 
situation, the input Service Interface clock frequency must be recovered at the output IWF. 
There are two techniques for recovering this clock; Synchronous Residual Time Stamp 
(SRTS) and Adaptive. Either technique may be used, although SRTS gives better control 
over wander introduced into the emulated circuit. 

4.4.1 SRTS 

The SRTS technique measures the Service Interface input clock frequency against a 
network-wide synchronization signal that must be present in the IWF, and sends difference 
signals, called Residual Time Stamps, in the AAL1 header to the reassembly IWF. At the 
output IWF, the differences can be combined with the network-wide synchronization 
signal to re-create the input Service Interface clock. 

(R-64) If SRTS is provided, it shall be used as specified in 1.363.1 and T1.630. 

(CR-18) The network derived clock frequency (f J used in the SRTS algorithm shall be 
77.76 MHz for DS3 and 38.88 MHz for E3 circuit emulation. 

4.4.2 Adaptive 

The adaptive technique does not require a network- wide synchronization signal to 
regenerate the input Service Interface clock at the output IWF. 

For a description of a possible technique to implement Adaptive clock recovery, see 
Section 3.4.2. 

Wander may be introduced by the Adaptive clock recovery technique if there is a low- 
frequency component to the Cell Delay Variation inserted by the ATM network carrying 
cells from the input to output IWF. 
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5. ATM Virtual Channel Requirements 

The subsections that follow specify traffic parameters and tolerances as defined in A. 6 of 
the UNI 3.1 Specification. 

The requirements described in this section must be met by the ATM network that provides 
an end-to-end ATM connection, i.e., from the input ATM Interface to the output ATM 
Interface in Figure 5-1. 
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Figure 5-1 : Reference Network Configuration 



(R-65) Quality of Service Class 1 for circuit emulation from the ATM Forum UNI 
Specification Version 3.1 Appendix A shall be used. 

5.1 Traffic Parameters and Tolerances 

Traffic policing may be performed on cells generated by the CES Interworking Function 
and transported by the ATM network. 

The CDV Tolerance parameter of the UPC should take into account any cell delay 
variation caused by the introduction of OAM cells. The CDV Tolerance should also 
account for any CDV that occurs in the intervening multiplexing and switching devices 
between the Interworking Function and the UPC device. 

In the context of this specification, CDV Tolerance is considered a network option, and is 
currently not subject to standardization. 

The following sections give the Peak Cell Rate (PCR) for various versions of the CES 
Interworking Function. 

In all cases, if the OAM traffic is to be included in the PCR per UNI 3.1 section 
3.6.3.2.3.7, then the OAM traffic parameter cells needs to be added to the above or 
specified separately. 
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5.1.1 Unstructured DS1 Cell Rate 

(R-66) The PCR on CLP=0+1 required for AAL1 transport of 1544 kbit/s user data is 4107 
cells per second. 

The calculation of the PCR is based on the following formula: 

4107 cells/second > (1.544 x 10 6 bits/s +130 ppm) / (47 AAL1 octets/cell x 8 bits/octet) 

5.1.2 Unstructured El Cell Rate 

(R-67) The PCR on CLP=0+1 required for AAL1 transport of 2048 kbit/s user data is 5447 
cells per second. 

The calculation of the PCR is based on the following formula: 

5447 cells/second > (2.048 x 10 6 bits/s + 50 ppm) / (47 AAL1 octets/cell x 8 bits/octet) 

5.1.3 Structured Nx64 Service Cell Rate 

5.1.3.1 Basic Service 

(R-68) If partial cell fill is not used and N is greater than one, the PCR on CLP=0+1 
required for AAL1 transport of Nx64 Basic Service isT(8000 x N)/46.875l cells per 
second (where M means "smallest integer greater than or equal to x"). If partial cell fill is 
used, the PCR is |~(8000 x N)/Kl, where K is the number of AAL-user octets filled per cell. 

(R-69) If partial cell fill is not used for 64 kbps Basic Service (i.e., when N is equal to 
one), the PCR on CLP=0+1 required for AAL1 transport is [8000/47] cells per second 
(where Txl means "smallest integer greater than or equal to x"). If partial cell fill is used, 
the PCR is [8000/Kl, where K is the number of AAL-user octets filled per cell. 

Both of these are derived by dividing the required user octet-rate by the number of user 
octets carried per cell. 

5.1.3.2 DS1/E1/J2 Service w/CAS 

(R-70) The PCR on CLP=0+1 required for AAL1 transport of El Nx64 Service w/CAS is: 

1 . No partial cell fill, N even: 

[8000 x[Nx33/32 ]/ 46.8751 

2. No partial cell fill, N odd: 

T8000 x [ (1 + Nx33) / 32 ] / 46.8751 

3. Partial cell fill, N even, K the number of AALl-user octets filled: 



Page 44 of 93 



ATM Virtual Channel Requirements CES-IS V2.0 af-vtoa-0078.000 

T8000 x [ Nx33/32 ] / Kl 

4. Partial cell fill, N odd, K the number of AALl-user octets filled: 
r8000x[( 1 +Nx33 )/32 ]/Kl 

(R-71) The PCR on CLP=0+1 required for AAL1 transport of DS1 Nx64 Service w/CAS 
is: 

1 . No partial cell fill, N even: 
r8000x[Nx49/48]/ 46.8751 

2. No partial cell fill, N odd: 

T8000 x [ (1 + Nx49) / 48 ] / 46.8751 

3. Partial cell fill, N even, K the number of AALl-user octets filled: 
T8000 x [ Nx49/48 ] / Kl 

4. Partial cell fill, N odd, K the number of AALl-user octets filled: 
T8000 x [ (1 + Nx49) / 48 ] / Kl 

(R-72) The PCR on CLP=0+1 required for AAL1 transport of J2 Nx64 Service w/CAS is: 

1 . No partial cell fill, N an exact multiple of 8: 

T8000 x [ Nx65/64 ] / 46.8751 

2. No partial cell fill, N not an exact multiple of 8: 
T8000 x [ ((8 - (N Modulo 8)) + Nx65) / 64 ] / 46.8751 

3. Partial cell fill, N an exact multiple of 8, K the number of AALl-user octets filled: 
T8000 x [ Nx65/64 ] / Kl 

4. Partial cell fill, N not an exact multiple of 8, K the number of AALl-user octets 
filled: 
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T8000 x [ ((8 - (N Modulo 8)) + Nx65) / 64 ] / Kl 

These rates are derived by dividing the effective user octet-rate (including block overhead) 
by the number of user octets carried per cell. 

Because all of the signalling bits are grouped together at the end of the AAL1 structure, 
virtual channels supporting DS1, El and J2 Nx64 Service with CAS will suffer some jitter 
in cell emission time. For example, an IWF carrying an Nx64 El circuit with N=30 and 
CAS enabled will, on average, emit about 10.5 cells spaced by 191.8 jisec, followed by a 
cell carrying CAS bits after a gap of only 130 |isec. This jitter in cell emission time must 
be accommodated by peak-rate traffic policers. 

5.1.4 Unstructured DS3 Cell Rate 

(R-73) The PCR on CLP-0+1 required for AAL1 transport of 44.736 Mbit/s + 20 ppm 
user data is 1 18,982 cells per second. 

The calculation of the PCR is based on the following formula: 

1 18,982 cells/second > (44.736 x 10 6 bit/s + 20 ppm) / (47 AAL1 octets/cell x 8 bits/octet) 

5.1.5 Unstructured E3 Cell Rate 

(R-74) The PCR on CLP=0+1 required for AAL1 transport of 34.368 Mbit/s + 20 ppm 
user data is 91,407 cells per second. 

The calculation of the PCR is based on the following formula: 

91,407 cells/second > (34.368 x 10 6 bits/s + 20 ppm) / (47 AAL1 octets/cell x 8 bits/octet) 

5.1.6 Unstructured J2 Cell Rate 

(R-75) The PCR on CLP=0+1 required for AAL1 transport of 6312 kbit/s +/- 30 ppm user 
data is 16,788 cells per second. 

The calculation of the PCR is based on the following formula: 

16,788 cells/second > (6.312 x 10 6 bits/s +30 ppm) / (47 AAL1 octets/cell x 8 bits/octet) 

5.2 ATM Virtual Channel Payload Type and CLP 

Sections 3.3 and 3.4 of the UNI 3.1 document specify that, in addition to Virtual Circuit 
and Virtual Path fields, the ATM cell header contains the Cell Loss Priority bit and the 
three-bit Payload Type Identifier field. 

5.2.1 Cell Loss Priority (CLP) 

(R-76) At the sender, this bit shall be set to "0". At the receiver, this bit shall be ignored. 
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5.2.2 Payload Type Identifier 

(R-77) All cells carrying emulated circuit data shall be sent with the Payload Type 
Identifier field set to 000, indicating "User Data cell, congestion not experienced, SDU- 
type=0". 

(R-78) All four User Data cell Payload Type Identifier values (000, 001, 010 and 01 1) 
shall be accepted by the receiver. 

5.3 Impairments 

Sections 2.1 and 3.1 specify performance characteristics of the CBR Service Interface. The 
ATM performance impairments should be commensurate with these. An initial mapping of 
service performance requirements to ATM performance requirements is provided in Annex 
A. 

5.3.1 Cell Transfer Delay 

Overall delay is often critical for Circuit Emulation applications, particularly those 
involving voice. Delay introduced by the ATM network interconnecting CES IWFs is 
composed of two components: 

Maximum Delay gives the largest expected cell delay between entrance and exit of the 
ATM network. 

Cell Delay Variation (CDV) gives the uncertainty in the delay that might be experienced 
by any particular cell. 

Circuit Emulation equipment must have reassembly buffers large enough to accommodate 
the largest CDV present on a virtual channel to prevent underflow or overflow, with 
resulting reframe or slip events. At the same time, it should be noted that reassembly 
buffers larger than required to accommodate CDV will result in excessive overall delay. 

The number of intervening switches, and their queue management, and line speeds have a 
significant impact on the distribution of CDV that must be handled by the reassembly 
buffer in the destination IWF. There are currently no standards that define a bound on 
CDV; however some information on CDV and reassembly buffer sizes can be found in 
GR-1 1 10-CORE and TA-TSV-001409. The BICI 1.1 specification, Section 5.1.2 gives an 
approximation of how CDV accumulates across multiple nodes. Implementors are advised 
to design the reassembly buffer in excess of these values, possibly making the size of the 
reassembly buffer configurable to optimize the jitter versus absolute delay trade-off in 
various configurations. 

The amount of CDV that the reassembly process can accommodate is configured with the 
MIB entry atmfCESCdvRxT. This entry allows the network provider to configure the 
maximum cell arrival jitter that the reassembly process will tolerate in the cell stream 
without producing errors on the CBR Service Interface. This parameter may be set to a 
small value if the connection will produce minimal CDV and a large value if the 
connection will produce large CDV. 
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An informative example of the implementation of a receiver which uses the 
atmfCESCdvRxT parameter is as follows: The receiver will place the contents of the first 
cell to arrive after an underrun into the receive buffer in a position such that it will be 
played out at least one CDVT (atmfCESCdvRxT) later. 
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6. Signalling 

This section specifies ATM UNI 3.1 signalling between the IWFs that support CES. There 
is no mapping specified between signalling that pertains to traditional DS1, El, J2 ,and 
Nx64 Services and ATM UNI 3.1 signalling. 

The call/connection control procedures of UNI 3.1 apply. The following section details the 
content of the setup message. CES signalling places no explicit constraints on other 
signalling messages. 

Note that UNI 3.1 SVC support is optional for the CES IWF. The following sections are 
applicable only when such SVC support is provided. 

6.1 Addresses and Identifiers for CES Switched Virtual Channels (SVCs) 

All CES SVCs are point-to-point. As with all SVCs, the endpoints must be identified 
during call setup with an ATM address; these may be of any of the three formats identified 
in section 5.1.3 of the UNI 3.1 Specification. Additional identifiers in the Broadband Low 
Layer Information (B-LLI) information element (IE) distinguish the particular type of CES 
SVC being set up. 

6.2 SETUP Message Contents 

Section 5.3.1.7 in the UNI 3.1 Specification lists the mandatory and optional information 
elements in the SETUP message. This CES specification places constraints on the values 
of certain fields in the following mandatory information elements: 

1. ATM Traffic Descriptor 

2. Broadband bearer capability 

3. QoS Parameter 

The following sections describe those constraints. 

The following information elements (which in general are optional) are required for CES 
signalling: 

1 . The AAL Parameters Information Element 

2. The Broadband Low Layer Information Element 

The required contents of these information elements are discussed in the following 
sections. 

The other information elements identified in UNI 3.1 Section 5.3.1.7 as optional remain 
optional for CES SVCs; this CES specification places no constraints on the values of the 
fields in these optional information elements. 
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Note that in the following sections we have omitted the fixed information element header 
fields and field identifiers from this specification; these should be inserted in the 
appropriate place in the information element. 

6.2.1 ATM Traffic Descriptor 

For CES SVCs, the following two fields in this information element must be specified: 

1 . Forward peak cell rate CLP=0+ 1 

2. Backward peak cell rate CLP=0+1 

The values for these fields should be calculated as specified in Section 5.1. 

The Best Effort Indicator and the Traffic Management Options Identifier must be omitted. 
We recommend that the other fields be omitted as well 

6.2.2 Broadband Bearer Capability 

The following table specifies the values for the fields in this information element. 



Field 


Value 


Bearer Class 


'1000 0' BCOB-X 


Traffic Type 


'00 T Constant bit rate 


Timing Requirements 


'01' End-to-end timing required 


Susceptibility to clipping 


'00' Not susceptible to clipping 


User Plane Connection Configuration 


'00' Point-to-point 



Table 6-1: Broadband Bearer Capability IE Field Values for CES SVCs 

6.2.3 Quality of Service Parameter 

The following table specifies the values for the fields in this information element. 



Field 


Value 


QoS Class Forward 


'0000 0001 'QoS Class 1 


QoS Class Backward 


'0000 000 P QoS Class 1 



Table 6-2: QoS Parameter IE Field Values for CES SVCs 



The Coding Standard field in this Information Element shall be coded as "11" when 
operating over ATM Forum compliant networks. However, when interfacing to an ITU 
conformant network that is not ATM Forum compliant, the Coding Standard shall be 
coded "00" and the QoS Class Forward and QoS Class Backward are each coded "0000 
0000", meaning QoS Class 0 — Unspecified QoS Class. 
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6.2.4 ATM Adaptation Layer Parameters 

The values in this information element vary with the particular choice of CES. The 
following six tables specify the field values for Nx64 Service, DS1 (+ Logical) 
Unstructured Service, El (+ Logical) Unstructured Service, J2 (+ Logical) Unstructured 
Service, DS3 (+ Logical) Unstructured Service, and E3 (+ Logical) Unstructured Service 
respectively. If the called party does not accept these parameters, it should release the call 
with cause 93 (AAL Parameters not Supported). 



Field 


Value 


AAL Type 


'0000 0001 'AAL Type 1 


Subtype 


'0000 0010' Circuit Transport 


CBR rate 


'0000 0001 ' 64kbit/s 

'0100 0000' Nx64 kbit/s, N>1 


Multiplier 


The value 'N' for Nx64 kbit/s. Omit field 
for 64 kbit/s case. 


Structured Data Transfer Blocksize 


Size in octets, as defined in Section 2.3.1 


Partially filled cells method 


K, the number of AAL-user octets filled 
per cell; see Section 2.2.2. Omit field if 
partial cell fill is not used 


Table 6-3: AAL Parameters IE Field Values for Nx64 Service SVCs 


Field 


Value 


AAL Type 


'0000 0001 'AAL Type 1 


Subtype 


'0000 0010' Circuit Transport 


CBR rate 


'0000 0100' 1544 kbit/s (DS1) 


Source Clock Frequency Recovery 
Method 


'0000 0000' Null (synchronous circuit 
transport) 


'0000 000 1' SRTS method (asynchronous 
circuit transport) 


'0000 0010' Adaptive method 
(asynchronous circuit transport) 



Table 6-4: AAL Parameters IE Field Values for DS1 Unstructured Service and DS1 

Logical Unstructured Service SVCs 
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Field 


Value 


AAL Type 


'0000 0001' AAL Type 1 


Subtype 


'0000 0010' Circuit Transnort 


CBR rate 


4 0001 0000' 2048 kbil/s (El) 


Source Clock Frequency Recovery 
Method 


0000 0000 Null (synchronous circuit 
transport) 


'0000 000 1' SRTS method (asynchronous 
circuit transport) 


'0000 0010' Adaptive method 
(asynchronous circuit transport) 



Table 6-5: AAL Parameters IE Field Values for El Unstructured Service and El Logical 

Unstructured Service SVCs 



Field 


Value 


AAL Type 


'0000 0001' AAL Type 1 


Subtype 


'0000 0010' Circuit Transport 


CBR rate 


'0000 010r 6312kbit/s 


Source Clock Frequency Recovery 
Method 


'0000 0000' Null (synchronous circuit 
transport) 


'0000 0001' SRTS method (asynchronous 
circuit transport) 


'0000 0010' Adaptive method 
(asynchronous circuit transport) 



Table 6-6: AAL Parameters IE Field Values for 32 Unstructured Service and J2 Logical 

Unstructured Service SVCs 



Field 


Value 


AAL Type 


'0000 000 1' AAL Type 1 


Subtype 


'0000 0010' Circuit Transport 


CBR rate 


'0000 0111' 44736 kbit/s (DS3) 


Source Clock Frequency Recovery Method 


'0000 0000' Null (synchronous circuit 
transport) 


'0000 0001' SRTS method (asynchronous 
circuit transport) 


'0000 0010' Adaptive method (asynchronous 
circuit transport) 



Table 6-7: AAL Parameters IE Field Values for DS3 Unstructured Service and DS3 

Logical Unstructured Service SVCs 
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Field 


Value 


AAL Type 


'nnnn nnni ' a at Tvnp 1 

UUWU UUU1 rVrVl^ lypc 1 


Subtype 


'0000 0010' Circuit Transport 




'0001 0010' 34368 kbit/s (E3) 


Source Clock Frequency Recovery Method 


'0000 0000' Null (synchronous circuit 
transport) 


'0000 0001 ' SRTS method (asynchronous 
circuit transport) 


'0000 0010' Adaptive method (asynchronous 
circuit transport) 



Table 6-8: AAL Parameters IE Field Values for E3 Unstructured Service and E3 Logical 

Unstructured Service SVCs 



6.2.5 Broadband Low Layer Information 

This information element identifies that the signaling entities are ATM Forum CES AAL 
User Entities as specified in this CES-IS. It also identifies the specific service and coding 
approach for Nx64 Service. 



Field 


Value 


User Information Layer 3 Protocol 
(octet 7) 


'01011' ISO/IEC TR 9577 


ISO/IEC TR 9577 Initial Protocol Identifier 
(IPI) 

(octet 7a, 7b) 


IPI is coded '1000 0000' to indicate IEEE 
802.1 SNAP identifier. Hence, octets 7a 
and 7b are coded as '0100 0000' and 
'0000 0000', respectively. 


Organizational Unit Identifier (OUI) 
(octets 8.1-8.3) 


x'00 AO 3E' ATM Forum OUI 


Protocol Identifier (PID) 
(octets 8.4-8.5) 


x'00 00' Ignored for Unstructured Service 


x'00 06' DS1/E1/J2 Nx64 Basic Service 


x'00 07' El Nx64 Service w/CAS 


x'00 08' DS1 SF Nx64 Service w/CAS 


x'00 09' DS1 ESF Nx64 Service w/CAS 


x'00 0B' J2 Nx64 Service w/CAS 



Table 6-9: Broadband Low Layer Information IE Field Values for CES SVCs 
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7. Call Initiation Procedures 

This chapter specifies optional procedures for the automatic initiation of an SVC between 
two CES entities. The purpose of specifying these procedures is to give meaning to the 
MIB variables they reference. Within this chapter, must and should apply only if the 
optional procedures are supported. 

7.1 Overview of SVC Procedures 

These procedures support automatic setup of an SVC between two circuit emulation 
processes. Using these procedures, the connection endpoints are provisioned via 
management action, identifying each endpoint by assigning them unique ATM addresses. 
Once provisioned, these procedures allow the endpoints to establish the connection, 
without further network management or user intervention. 

A process supporting SVCs may be provisioned to support 2 modes: 

• passive, in which it only awaits incoming calls and does not initiate outgoing calls, and 

• active, in which it makes call attempts periodically whenever a call is not in progress. 
In this mode, it is also possible to configure the process to cease call attempts after a 
configured number of failed attempts. 

This specification gives the flexibility to the operator through setting of the MIB variables 
to either have both ends retry calls until successful, or have calls initiated only by a single 
end. 

Note that since the parameters of this type of connection are established administratively, 
separate from the processes that establish the connection itself, negotiation of end to end 
parameters is not possible. For example, traffic parameters will not be negotiable. If any of 
the configured parameters cannot be supported by the switching network, the call 
establishment will fail. 

7.2 MIB Variables 

The CES Active SVC Table (atmfCESActiveSvcTable) contains the information necessary 
for control and management of the automatic SVC initiation procedures. For more 
information on the creation and deletion of rows in this table, refer to section 8. Twelve 
variables are defined in the atmfCESActiveSvcEntry for use by active and passive SVC 
processes. For information on these variables, refer to the atmfCESActiveSvcTable section 
of the CES Version 2 MIB in section 8.4.2. 

Note that atmfCESLocalAddr is the ATM address of the local circuit emulation process. 
For a device supporting only a single circuit emulation process, this could be the only 
ATM address assigned to that device on the ATM network. However, it is presumed that 
many implementations will include many circuit emulation processes, so that multiple 
ATM addresses are assigned to the device. It is possible that these ATM addresses differ 
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only in the value of the selector byte, but that is not required by this specification. This 
specification does require that each distinct CES entity have a different ATM address. 

Note also that atmfCESConnType specifies whether the local circuit emulation process is 
supposed to initiate calls. If the value is "pvc", the process does whatever internal 
procedures it needs to be connected to a PVC on a particular VPI VCI. If the value is 
"activeSvc", the process follows the procedures described in "Active SVC Procedures" 
below. If the value is "passiveSvc", the process does whatever internal procedures it needs 
to be able to receive ATM calls directed to "atmfCESLocalAddr". 



7.3 Active SVC Procedures 

In order to configure a circuit emulation process to initiate ATM calls, the following steps 
are taken: 

1 . The atmfCESConfEntry for the local circuit emulation process must first be 
configured with a local address (in atmfCESLocalAddr) and a connection type of 
'activeSvc' (in atmfCESConnType). When the atmfCESConnType is set to 
'activeSvc', a corresponding entry in the atmfCESActiveSvcTable is created by 
the agent. 

2. The atmfCESActiveSvcEntry must then be configured with the address of the 
remote circuit emulation process - i.e., the "other" end of the logical facility being 
emulated. In addition, other parameters used to specify the retry behavior used 
when call attempts fail or the call is cleared may be configured. Once the 
atmfCESRemoteAddr has been configured, call attempts are initiated. 

A circuit emulation process which has atmfCESConnType set to 'activeSVC should 
initiate calls to the specified remote address whenever the atmfCESRemoteAddr has been 
configured and the ATM link is available, but there is no call active. No call attempts are 
made when no remote address has been specified. If the value of the remote address 
changes while an SVC call is established, the established call must be cleared. 

Unsuccessful calls should be retried at a rate governed by atmfCESFirstRetrylnterval, as 
long as the atmfCESRetryFailures count has not reached the value specified in 
atmfCESRetryLimit (if non-zero). 

Once the number of such failures reaches the configured limit value, no further call 
attempts will be made. Call establishment procedures can then be started again only by 
network management action to set the value of atmfCESConnectionRestart to 'restart', at 
which time the atmfCESRetryFailures count will be cleared and the call establishment 
process restarted. 

7.4 Call Collision 

If a circuit emulation process receives a valid incoming call while it has an outgoing call in 
progress, it should compare the value of the source and destination ATM addresses in the 
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incoming call. If the source address is smaller than the destination address, the incoming 
call should be accepted, and the outgoing call cleared. Otherwise, the incoming call should 
be cleared. 

7.5 Call Retry 

Note that strict adherence to precisely the retry interval indicated by 
atmfCESFirstRetrylnterval is to be avoided. Rather, the implementation should apply some 
random differential from this value on each retry. In addition, it may be desirable to 
increase the retry interval on each retry in order to implement a backoff scheme when 
successive retries continue to fail. 
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8. Management 

In general, the CES IWF will be implemented in equipment that supports one or more 
ATM ports and one or more CBR interfaces (typically DS1 and/or El ports). Thus, the 
equipment that incorporates one or more IWFs will have an "ATM side", a "CBR side" 
(corresponding to the Service Interface), and a set of entities that cause the two to 
interwork. The ATM Forum's Network Management Working Group is specifying the 
management of the ATM equipment (the "ATM side"). In addition, the ATM Forum's 
Network Management Working Group is also addressing the AAL and CES management 
protocol independent requirements, plus CMIP MIBs. However, the Network Management 
Working Group will not address the SNMP MIBs for the management aspects pertaining to 
the Service Interface and interworking entities: 

1. The DS1, El, J2, DS3 or E3 Service Interfaces 

2. DSO or DSO Bundle Entities 

3 . The CES Mapping Functions 

4. The AAL 1 entities 

This section describes the management of CES IWF via SNMP or SNMPv2. If SNMP is 
implemented in a device this section specifies the implementation. It is outside the scope of 
this document to specify a MIB for CMIP. The relationships between different logical and 
physical interfaces is described in accordance with IETF RFC 1573. This MIB is written in 
compliance with SMIv2 RFC 1442. 
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One of the basic functions of this section is to define cross-connections between Constant 
Bit Rate Service interfaces and ATM interfaces. The example shown in Figure 8-1 below 
depicts how a single device can have multiple CES IWF entities mapping CBR interfaces 
to ATM interfaces. The number in "()" represents a unique number identifying each 
interface called the instance number or iflndex as described in RFC 1573. For each 
iflndex listed in Figure 8-1, there is one ifTable entry as defined in RFC 1573. RFC 1573 
also describes the layering of one interface above and below another interface. This section 
defines the interfaces per RFC 1573, the layering of the interfaces per RFC 1573, the DSO 
channel to CES IWF mapping per RFC TBD (the new IETF DSO MIB), and finally the 
CES SMIv2 MIB. 




ATM (2) 



Figure 8-1: CES IWF Instances Mapping CBR Instances to ATM Instances 



Management information for the CES IWF is organized into four tables in the CES 
Version 2 MIB: the CES Configuration Table, the CES Mapping Table, the CES Statistics 
Table, and the CES Active SVC Table. 

Basic configuration information for a CES IWF is managed via the CES Configuration 
Table (atmfCESConfTable). An instance of the management information for a CES IWF is 
created in this table by a management entity via the creation of a row of objects. This 
creation is an action by a managing system because there is typically not a fixed or 
predetermined relationship between the CES IWF and the physical interfaces for which it 
provides circuit emulation service, or even between the CES IWF and the management 
entities for the physical interfaces (e.g., the DS1 MIB entities) or the logical interfaces 
(e.g., DSO MIB or DSOBundle MIB entities) for which it provides circuit emulation 
service. Consequently this relationship is established by the creation of the entry in the 
atmfCESConfTable. This creation process is controlled by the atmfCESConfRowStatus 
object, as described by the SNMPv2 SMI. Similarly, deletion of an instance of 
management information for a CES IWF is accomplished by the deletion of the 
corresponding row in the CES Configuration Table (atmfCESConfTable). 
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Performance information is maintained for the CES IWF in the CES Statistics Table 
(atmfCESStatsTable). Creation of the row in the atmfCESConfTable automatically causes 
the creation of a corresponding row of objects in the atmfCESStatsTable. Likewise, 
deletion of a row in the atmfCESConfTable will cause the deletion of the corresponding 
row in the atmfCESStatsTable. Thus there will always be a one-to-one relationship 
between rows in these two tables. 

The ability to identify the CES IWF which is associated with a known ATM interface, VPI 
and VCI is provided by the CES Mapping Table (atmfCESMappingTable). An entry in this 
table is automatically created for every atmfCESConfTable entry with a non-zero 
atmfCESAtmlndex. Likewise, an entry in this table is deleted from this table when the 
atmfCESAtmlndex in the corresponding atmfCESConfTable entry is either set to zero or 
when that corresponding atmfCESConfTable entry is deleted. 

Note that the ability to identify the CES IWF which is associated with a known CBR 
interface (or related logical interface), if any, is provided by the CES Configuration Table 
itself. Entries in this table are indexed by atmfCESCbrlndex, which is defined to be equal 
to MIB II's iflndex value for that CBR physical or logical interface. And since both the 
ATM interface index (atmfCESAtmlndex) and the CBR interface index 
(atmfCESCbrlndex) are also included in the CES Configuration Table, it is then possible 
to trace a connection from the CES IWF to both its ATM and CBR interfaces as well as 
from either the ATM or CBR interface to the corresponding CES IWF. Thus the full 
connection can be traced once any object in this connection is known. 

The ability to support automatic establishment of a virtual channel connection over the 
ATM network for a CES IWF is provided by the CES Active SVC Table 
(atmfCESActiveSvcTable). An entry in this table is automatically created for each active 
row in the CES Configuration Table (atmfCESConfTable) with a connection type 
(atmfCESConnType) equal to 'activeSVC. This CES Active SVC Table entry can then be 
configured with the information necessary to control and manage the automatic 
establishment of the needed SVC. For further information on this process, refer to Section 
7. 
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8.1 CES IWF Interfaces (per RFC 1573) 

Each interface (e.g. ATM and CBR) shall have a single entry in the ifTable as defined by 
RFC 1573. This ensures all instance numbers are unique and allows the CES IWF to define 
which variables in the CES MIB may cause CES IWF linkup and linkdown traps to be 
generated. The CES MIB then provides a mechanism to relate to the CBR interface for 
which it provides service and to the ATM interface over which this service is provided. 
The following tables are sample ifTable entries. 



RFC 1573 Objectld 


Value 


Description 


iflndex 


9 


Unique number to identify an interface. 


IfDescr 


"CBR mapped 
to CES #3 and 
CES #4" 


This is a string of up to 255 characters used to 
describe the interface. In this case it is useful to 
describe that this CBR (9) interface is mapped 
to CES #3 and CES #4. 


IfType 


dsl (18) 


A CBR interface defined by RFC TBD (the new 
IETF DS1 MIB) which defines interfaces of 
ifType equal to dsl (18). 


IfSpeed 


1,544,000 


Bits per second speed of interface. 


IfAdminStatus 


up(l) 


Value is up (1) or down (2) depending on 
whether the interface has been administratively 
configured. 


IfOperStatus 


up (I) 


This object is set to the value down (2) if the 
object dsxlLineStatus has any value other than 
dsxlNoAlarm(l) or ifAdminStatus is down (2). 


IfLastChange 


0 


Time when operational state last changed. 


IfLinkUpDownTrapEnable 


enabled (1) 


Enable/Disable the sending of LinkUp and 
LinkDown traps. If enabled, LinkUp or 
LinkDown traps will be sent based on the value 
of ifOperStatus. 


IfName 


"CBR_9" 


A string representing the interface. This allows 
other devices to use the same name and perform 
functions like "ping" without knowledge of 
cryptic numbers. 



Table 8-1: Sample CBR (9) ifTable entry of ifType dsl (18) 
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RFC 1573 Objectld 


Value 


Description 


iflndex 


10 


Unique number to identify an interface. 


IfDescr 




l nis is a siring 01 up iu ciiaracicrs u»cu iu 
describe the interface. 


IfType 


ds3 (30) 


DS3 interfaces are defined by RFC TBD (the new 

FPTF MTFn u/hirh defines intf»rfarp<; nf ifTvne 

equal to ds3 (30). 


IfSpeed 


44,736,000 


Bits per second speed of interface. 


IfAdminStatus 


up (1) 


Value is up (1) or down (2) depending on whether 

thfi Ar\tf*r~far k f* Vine Kppn ciHtTiinictrsitivpIv fnnficnirpn 
UlC llllCllcK/C Ilai> UCCU aUIllllllillall VCljr tUUllgUivu. 


IfDperStatus 


up(l) 


This object is set to the value down (2) if the object 
dsx3 Line Status has any value other than 
dsx3NoAlarm(l) or ifAdminStatus is down (2). 


IfLastChange 


0 


Time when operational state last changed. 


IfLinkUpDownTrapEnable 


enabled (1) 


Enable/Disable the sending of LinkUp and 
LinkDown traps. If enabled, LinkUp or LinkDown 
traps will be sent based on the value of ifOperStatus. 


ifName 


"ATM 1 - 
DS3_10" 


A string representing the interface. 



Table 8-2: Sample DS3 (10) ifTable entry of ifType ds3 (30) 
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RFC 1 573 Obiectld 


Value 


Description 


liinuex 


i 

i 


TTninne number to identifv an interface 


IfDescr 


"ATM 

CES #1, CES 
#2, and CES 
#3. " 


This is a string of up to 255 characters used to 

Hesrribe the interface Tn this rase it is useful to 

UvovllUC lilt/ lllLWl J-OW. All llllo ^CUb 11 IJ UijvlUl LV_/ 

describe that this ATM (1) interface is mapped to 
CES #1, CES #2, and CES #3. 


IfType 


atm (37) 


ATM interfaces are defined by RFC 1695. 


IfSpeed 


44,736,000 


Bits per second speed of interface. 


i i/\arnino laius 


■ in (\\ 
up (I) 


Value i'q nn (\ \ c\r Hnwn O^i Henendintr on whether 

the interface has been administratively configured. 


IfOperStatus 


up(l) 


Assumes the value down(2) if the ATM cell layer or 
any layer below that layer is down. 


IfLastChange 


0 


Time when operational state last changed. 


IfLinkUpDownTrapEnable 


enabled (1) 


Enable/Disable the sending of LinkUp and 
LinkDown traps. If enabled, LinkUp or LinkDown 
traps will be sent based on the value of ifOperStatus. 


ifName 


"ATM_1" 


A string representing the interface. This allows other 
devices to use the same name and perform functions 
like "ping" without knowledge of cryptic numbers. 



Table 8-3: Sample ATM (1) ifTable entry of ifType atm (37) 
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RFC 1573 Objectld 


Value 


Description 


iflndex 


7 


Unique number to identify an interface. 


ifDescr 


"A/fane PF^ 

#1 to Logical 
(7)" 


Thic ic a ctrincr nf nn in ?5S characters used to 

1 Ilia ia a oiling yJ * ti|J nj ~> viicua^Lvik) uowu v\j 

describe the interface. 


ifType 


other (1) 


There is no IANAifType defined for logical; 
therefore, other must be used. 


ifSpeed 


0 


Value depends on the meaning of logical interface. 


ifAdminStatus 


up (1) 


Value is up (1) or down (2) depending on whether 
the interface has been administratively configured. 


ifOner SI tarns 




Interface dependent. 


ifLastChange 


0 


Time when operational state last changed. 


ifLinkUpDownTrapEnable 


enabled (1) 


Enable/Disable the sending of LinkUp and 
LinkDown traps. If enabled, LinkUp or LinkDown 
traps will be sent based on the value of ifOperStatus. 


ifName 


"Logical" 


A string representing the interface. This allows other 
devices to use the same name and perform functions 
like "ping" without knowledge of cryptic numbers. 



Table 8-4: Sample Logical (7) ifTable entry of ifType other (1) 



8.2 CES IWF Layers (per RFC 1573) 

Figure 8-2 shows the layers required and which MIBs are used to manage each layer. 



< ► 

ATM Interface 

(Shaded boxes are specified elsewhere) 
Figure 8-2: CES Layers from CBR Interface to ATM Interface 
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8.3 CES IWF to DSO Mapping (per RFC TBD [the new IETF DSO MIB]) 

It is possible to map DSO channels from one CBR interface to multiple CES IWFs. This is 
NOT accomplished in the CES MIB. This is accomplished in the RFC TBD DSO MIB by 
means of the dsOBundle object. The dsOBundle allows a group of timeslots (dsO's) to be 
mapped to a CES IWF. Each timeslot may be mapped to a unique instance number, or an 
instance number sharing one or all other timeslots. Figure 8-3, which is based on Figure 8- 
1, shows a dsOBundle (20) instantiated to bundle timeslots 1 through 4 together for one 
CES IWF and another dsOBundle (21) instantiated to bundle timeslots 5 through 8 together 
for a different CES IWF. The iflndex values (12 through 19) for the dsO instances are also 
illustrated in the figure. 




CES IWF #3 




dsOBundle 
(20) 



(using timeslots 1-4) 




dsOBundle 
(21) 



(using timeslots 5-8) 




CBR (9) 



[ ] = timeslot (dsO) number 
( ) = iflndex value 



Figure 8-3: ATM, CES and CBR Mappings 
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The following tables illustrate sample ifTable entries for the dsOBundle (20) and dsO (12) 
of the above example. 



RFC 1573 Objectld 


Value 


Description 


iflndex 


20 


Unique number to identify an interface. 


IfDescr 


"dsO iflndexes 
12-15 mapped 
to CES #3" 


This is a string of up to 255 characters used to 
describe the interface. In this case it is useful to 
describe that the dsO interfaces (iflndexes 12-15) 
are mapped to CES #3. 


IfType 


dsOBundle 
(82) 


dsOBundles are defined by RFC TBD (the new 
IETF DSO MIB) with ifType equal to 
asuounaie \oZ). 


IfSpeed 


256,000 


Bits per second speed of interface. Nx64000 for 
dsOBundles. 








ifAdminStatus 


up(l) 


Value is up (1) or down (2) depending on 
whether the interface has been administratively 
configured. 


1 iKjp er 0 1a rus 


up ^1; 


Tfiw nHif*pt i*q Qpt tc\ thf* vflliif* down (l^i if 

X IJXo VJUM^Wl Xd dvl l\J lilt VAX Lit UUW11 \ ) 

ifAdminStatus is down (2). 


ifLastChange 


0 


Time when operational state last changed. 


ifName 


"DS0B_20" 


A string representing the interface. This allows 
other devices to use the same name and perform 
functions like "ping" without knowledge of 
cryptic numbers. 


ifLinkUpDownTrapEnable 


disabled (2) 


Must be set to disabled (2). 


ifHighSpeed 


(0) 


Must be set to (0) 


ifConnectorPresent 


false (2) 


Must be set to false (2) 



Table 8-5: Sample dsOBundle (20) ifTable entry of ifType dsOBundle (82) 
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RFC 1573 Objectld 


Value 


Description 


iflndex 


12 


Unique number to identify an interface. 


ifDescr 


"dsO timeslot 
1" 


This is a string of up to 255 characters used to 
describe the interface. In this case it is useful to 
describe the DSO timeslot. 


ifType 


dsO (81) 


dsOs are defined by RFC TBD (the new IETF 
DSO MIB) with ifType equal to dsO (81). 


ifSpeed 


64000 


Bits per second speed of interface. 








ifAdminStatus 


up(l) 


Value is up (1) or down (2) depending on 
whether the interface has been administratively 
cuniigiucu. 


liUperotatus 


up (I) 


TVno /Vhi^r't io Qf*t tn trip vnlnp Hnwn (0\ i"P 
1 nia OUJCt/l lo oCl L\J 11JC VttlUC LIU W 11 11 

ifAdminStatus is down (2). 


ifLastChange 


0 


Time when operational state last changed. 


ifName 


M timeslot_r 


A string representing the interface. This allows 
other devices to use the same name and perform 
functions like "ping" without knowledge of 
cryptic numbers. 


ifLinkUpDownTrapEnable 


disabled (2) 


Must be set to disabled (2). 


ifHighSpeed 


(0) 


Must be set to (0) 


ifConnectorPresent 


false (2) 


Must be set to false (2) 



Table 8-6: Sample dsO (12) ifTable entry of ifType dsO (81) 
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The objects managing the CBR interface and DSO channels are linked together via the 
ifStackTable, as defined in RFC 1573. Table 8-7 below displays all ifStackTable entries 
for the mappings shown in Figure 8-3. 



ifStackTable Entries 
HigherLayer LowerLayer 


0 


20 


0 


21 


20 


12 


20 


13 


20 


14 


20 


15 


21 


16 


21 


17 


21 


18 


21 


19 


12 


9 


13 


9 


14 


9 


15 


9 


16 


9 


17 


9 


18 


9 


19 


9 


9 


0 



Table 8-7: Example ifStackTable Entries 
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8.4 CESMIB 



8A1 CES Version 1 MIB 

The CES Version 1 MIB from af-saa-0032.000 (reproduced below) has been deprecated 
and totally replaced by the CES Version 2 MIB. This following CES Version 1 MIB 
should not be used for new designs. 

The entire CES Version 1 MIB is mandatory. 



ATMF-CES-MIB DEFINITIONS ::= BEGIN 



IMPORTS 

enterprises 

OBJECT -TYPE, MODULE- IDENTITY, Counter32 
TEXTUAL - CONVENT I ON 
if Index 



FROM RFC1155-SMI 
FROM SNMPv2 -SMI 
FROM SNMPV2-TC 
FROM IF-MIB; 



atmForum 

atmForumNetworkManagement 
atmfCESmib OBJECT 



OBJECT IDENTIFIER ::= j enterprises 353 } 
OBJECT IDENTIFIER ::= { atmForum 5 } 
IDENTIFIER ::= { atmForumNetworkManagement 2 



atmfDSlElCESmib MODULE- IDENTITY 
LAST - UPDATED " 950203 0000Z" 

ORGANIZATION "ATM Forum Circuit Emulation Working Group" 

CONTACT- INFO " f edorkow@cisco . com, myron@kentrox. com" 

DESCRIPTION "This MIB module is deprecated, and is being replaced 

by the atmfCES module as a more generic Circuit 

emulation MIB. 

The MIB module to describe the DS1/E1 

Circuit Emulation Interworking Function (Version 1.0)" 
: : = { atmfCESmib 1 } 

--an OBJECT IDENTIFIER for all ATM Forum circuit emulation MIBs 
-- has been assigned as a branch from the Forum Network Management 
-- tree. The DS1/E1 Circuit Emulation specification is attached 
--as the first branch from the overall atmfCESmib object. Future 
-- branches may be added in the future for further CES work, for 
-- example, DS3/E3 circuit emulation. 

this is the MIB module for the ATM Forum DS1/E1 Circuit Emulation 
Interworking Function objects 

-- the following TEXTUAL -CONVENT IONS are used to link the CES 
-- interworking function to ATM interface port, plus the 
associated VPI and VCI . 



Vpilnteger ::= TEXTUAL- CONVENTION 
STATUS deprecated 
DESCRIPTION 

"An integer large enough to hold a VPI" 
SYNTAX INTEGER (0..4095) 



Vcilnteger = TEXTUAL -CONVENTION 
STATUS deprecated 
DESCRIPTION 

"An integer large enough to hold a VCI" 
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SYNTAX INTEGER (0.. 65535) 

CESConnectionPort ::= TEXTUAL -CONVENTION 
STATUS deprecated 
DESCRIPTION 

"Indicates the port associated with a Circuit Emulation 
connection. 

Objects of this type are always define as part of a set 
that includes 

fooPort CESConnectionPort 

fooVPI Vpi Integer 

fooVCI Vci Integer 

The interpretation of these objects is as follows: 

1. If no connection exists, x f ooPort ■ has a value of 0. 
Because Interfaces table entries always have * if Index' 
values greater than 0, v fooPort' reliably serves as a 
Connection exists' flag. 

If no connection exists, *fooVPI' and * f ooVCI 1 are 
meaningless and have a value of 0. 

2. If a PVC or SVC exists, fooPort is defined to have the 
value of the MIB- II/RFC1573 1 if Index' of the ATM 
interface associated with the VCC. *fooVPI' and * f ooVCI ■ 
will contain its VPI/VCI." 

SYNTAX INTEGER ( 0 2147483647) 

atmfDSlElCESmibObjects OBJECT IDENTIFIER ::= {atmfDSlElCESmib 1} 

atmfDSlElCESConf Table OBJECT-TYPE 

SYNTAX SEQUENCE OF AtmfDSlElCESConf Entry 
MAX-ACCESS not-accessible 
STATUS deprecated 
DESCRIPTION 

"The CES configuration table. This includes mapping channels from 
ATM Port to CBR interfaces. There is one AtmfDSlElCESConf Entry 
per CES Entity" 
::= { atmfDSlElCESmibObjects 1 } 

atmfDSlElCESConf Entry OBJECT-TYPE 
SYNTAX AtmfDSlElCESConf Entry 
MAX- ACCESS not -accessible 
STATUS deprecated 
DESCRIPTION 

"An entry in the CES table. For each entry there is a corresponding 
entry in the stack table" 
INDEX { if Index } 
::= { atmfDSlElCESConf Table 1 } 

AtmfDSlElCESConf Entry : : = SEQUENCE { 
a tmf DS 1 E 1 CESMapATM Index 
atmfDSlElCESMapVPI 
atmfDSlElCESMapVCI 
atmfDSlElCESCBRService 
atmfDSlElCESCBRClockMode 
atmfDSlElCESCas 
atmfDSlElCESPartialFill 
atmfDSlElCESBufMaxSize 
atmf DSlElCESCDVRxT 

atmfDSlElCESCellLossIntegrationPeriod 

} 

atmfDSlElCESMapATMIndex OBJECT-TYPE 
SYNTAX CESConnectionPort 
MAX-ACCESS read-only 
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STATUS deprecated 
DESCRIPTION 

"The value of this object is equal to MIB II* s 
if Index value of the ATM Port interface mapped 
through this CES to a CBR interface." 
::= { atmfDSlElCESConf Entry 1 } 

atmfDSlElCESMapVPI OBJECT-TYPE 
SYNTAX Vpi Integer 

MAX-ACCESS read-only 
STATUS deprecated 
DESCRIPTION 

"The value of this object is equal to the VPI used 
for the emulated circuit represented by this entry 
in the if Table. If there is no connection, this 
object is meaningless and will have the value zero." 
::= { atmfDSlElCESConf Entry 2 } 

atmfDSlElCESMapVCI OBJECT-TYPE 
SYNTAX Vci Integer 

MAX-ACCESS read-only 
STATUS deprecated 
DESCRIPTION 

"The value of this object is equal to the VCI used 
for the emulated circuit represented by this entry 
in the if Table. If there is no connection, this 
object is meaningless and will have the value zero" 
::= { atmfDSlElCESConf Entry 3 } 

atmfDSlElCESCBRService OBJECT- TYPE 

SYNTAX INTEGER { 

unstructured (1) , 
structured (2) 

} 

MAX-ACCESS read-write 
STATUS deprecated 
DESCRIPTION 

"Define if DS1/E1 service as structured or not. A 
structured (2) interface is some nx64Kbps. An unstructured 
(1) interface is 1.544Mbps or 2.048Mbps. Unstructured ( 1) 
passes all bits through the ATM network. 

strucutured(2) passes data bits through the ATM network, and 
may also pass signalling bits" 
::= { atmfDSlElCESConf Entry 4 } 

atmfDSlElCESCBRClockMode OBJECT-TYPE 
SYNTAX INTEGER { 

synchronous (1) , 
srts (2) , 
adaptive (3 ) 

} 

MAX- ACCESS read- write 
STATUS deprecated 
DESCRIPTION 

"Define if DS1/E1 service clocking mode. This maps into 
transmit clock source of CBR interface." 
DEFVAL { synchronous } 

{ atmfDSlElCESConf Entry 5 } 

atmfDSlElCESCas OBJECT-TYPE 
SYNTAX INTEGER { 

basic (1) , 
elCas (2) , 
dslSfCas(3) , 



Page 70 of 93 



Management 



CES-IS V2.0 



af-vtoa-0078.000 



dslEsfCas(4) 
} 

MAX- ACCESS read- write 
STATUS deprecated 
DESCRIPTION 

"This parameter selects which AAL1 Format should be used: 
Basic does not carry CAS bits, and uses a single 125 usee frame. 
elCas, dslSfCas and dSlEsfCas carry CAS bits in a multiframe 
structure for El, DS1 SF and DS1 ESF respectively. 

This applies to structured interfaces only. Default is basic (l). n 
DEFVAL { basic } 

{ atmfDSlElCESConf Entry 6 } 

atmfDSlElCESPartialFill OBJECT-TYPE 
SYNTAX INTEGER (0 47) 
MAX- ACCESS read- write 
STATUS deprecated 
DESCRIPTION 

"If partial cell fill is used, the number of user octets per 
cell must be set with this parameter. Setting this parameter 
to zero disables partial cell fill, and causes all cells to 
be completely filled before they are sent." 

DEFVAL { 0 } -- Partial Cell Fill not used 

::= { atmfDSlElCESConf Entry 7 } 

a tmf DS IE ICESBuf MaxS i z e OBJECT - TYPE 

SYNTAX INTEGER (1.. 65536) 

MAX-ACCESS read-write 
STATUS deprecated 
DESCRIPTION 

"Define maximum size in octets of the reassembly buffer. 
Some implementations may want allow the maximum buffer size to 
programmed to a size less than the physical limit to reduce 
the maximum delay through a circuit." 
DEFVAL { 256 } 

::= { atmfDSlElCESConf Entry 8 } 

atmf DSlElCESCDVRxT OBJECT -TYPE 

SYNTAX INTEGER (1.. 65535) 

UNITS "10 usee" 
MAX-ACCESS read-write 
STATUS deprecated 
DESCRIPTION 

"The maximum cell arrival jitter in 10 usee increments that 
the reassembly process will tolerate in the cell stream without 
producing errors on the CBR service interface . " 
DEFVAL { 100 } 

::= { atmfDSlElCESConf Entry 9 } 

atmfDSlElCESCellLossIntegrationPeriod OBJECT-TYPE 
SYNTAX INTEGER (1000 . . 65535) 
UNITS "msec" 
MAX-ACCESS read-write 
STATUS deprecated 
DESCRIPTION 

"The time in milliseconds for the cell loss integration period. 
If a cells are lost for this period of time. 
atmfDSlElCESCellLossStatus is set to loss (2) .The current 
definition is 2500." 
DEFVAL { 2500 } 

::= { atmfDSlElCESConf Entry 10 } 

atmfDSlElCESStatsTable OBJECT -TYPE 

SYNTAX SEQUENCE OF Atmf DSlElCESStatsEntry 
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MAX- ACCESS not -accessible 
STATUS deprecated 
DESCRIPTION 

"The CES AAL1 statistical data table." 
::= { atmfDSlElCESmibObjects 2 } 

atmfDSlElCESStatsEntry OBJECT-TYPE 
SYNTAX AtmfDSlElCESStatsEntry 
MAX- ACCESS not -accessible 
STATUS deprecated 
DESCRIPTION 

"An entry in the CES AAL1 Stats table." 
INDEX { if Index } 
::= { atmfDSlElCESStatsTable 1 } 

AtmfDSlElCESStatsEntry ::= SEQUENCE { 

atmf DSlElCESReassCells Counter32 , 

atmf DSlElCESHdrErrors Counter32 , 

atmf DSlElCESPointerRef rames Counter32 , 

atmf DSlElCESLostCells Counter32 , 

atmf DSlElCESBuf Underflows Counter32 , 

atmf DSlElCESBuf Overflows Counter32 , 

atmfDSlElCESCellLossStatus INTEGER 

} 

atmfDSlElCESReassCells OBJECT-TYPE 
SYNTAX Counter 3 2 

MAX-ACCESS read-only 
STATUS deprecated 
DESCRIPTION 

"This count gives the number of cells played out to the DS1/E1 
Service Interface. It excludes cells that were discarded for 
any reason, including cells that were not used due to being 
declared misinserted, or discarded while the reassembler was 
waiting to achieve synchronization." 
::= { atmfDSlElCESStatsEntry 1 } 

atmf DSlElCESHdrErrors OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS deprecated 
DESCRIPTION 

"The count of the number of AAL1 header errors detected and 
possibly corrected. Header errors include correctable and 
uncorrectable CRC, plus bad parity." 
::= { atmfDSlElCESStatsEntry 2 } 

atmf DSlElCESPointerRef rames OBJECT-TYPE 
SYNTAX Counter 3 2 

MAX-ACCESS read-only 
STATUS deprecated 
DESCRIPTION 

"This records the count of the number of events in which the 
AAL1 reassembler found that an SDT pointer is not where it is 
expected, and the pointer must be reacquired." 
::= { atmfDSlElCESStatsEntry 3 } 

atmf DSlElCESLostCells OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS deprecated 
DESCRIPTION 

"Number of lost cells." 
{ atmfDSlElCESStatsEntry 4 } 
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atmfDSlElCESBuf Underflows OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS deprecated 
DESCRIPTION 

"Number of buffer underflows." 
::= { atmfDSlElCESStatsEntry 5 } 

atmfDSlElCESBuf Overflows OBJECT -TYPE 

SYNTAX Counter32 
MAX- ACCESS read-only 
STATUS deprecated 
DESCRIPTION 

"Number of buffer overflows." 
::= { atmfDSlElCESStatsEntry 6 } 

atmfDSlElCESCellLossStatus OBJECT-TYPE 
SYNTAX INTEGER { 

noLoss (1) , 
loss (2) 
} 

MAX-ACCESS read-only 
STATUS deprecated 
DESCRIPTION 

"When cells are lost for the number of milliseconds specified 
by atmfDSlElCESCellLossIntegrationPeriod, the value is set to 
loss (2) . When cells are no longer lost, the value is set 
to noLoss (1) . " 
{ atmfDSlElCESStatsEntry 7 } 

END 



8.4.2 CES Version 2 MIB 

The following CES Version 2 MIB provides the SNMPv2 Network Management interface 
to the CES Version 2 Interworking Function (IWF). 

ATMF-CES DEFINITIONS ::= BEGIN 

IMPORTS 

enterprises 

OBJECT-TYPE, MODULE- IDENTITY, Counter32 , 
Gauge 3 2 

TEXTUAL - CONVENT I ON , Ro wS t a t u s 
Interface Index 

MODULE -COMPLIANCE, OBJECT -GROUP 

atmfCES MODULE- IDENTITY 

LAST-UPDATED " 9611050000Z " 

ORGANIZATION "ATM Forum Circuit Emulation Working Group" 
CONTACT- INFO "The ATM Forum 

2570 West El Camino Real, Suite 3 04 

Mountain View, CA 94040-1313 USA 

Phone: +1 415-949-6700 

Fax: +1 415-949-6705 

inf o@atmf orum. com" 
DESCRIPTION "The MIB module used to describe the 

Circuit Emulation Interworking Function 

(Version 2.0) " 
REVISION " 950203 0000Z" 

DESCRIPTION "The MIB Module to describe the DSl/ElCircuit 



FROM RFC1155-SMI 

FROM SNMPv2-SMI 
FROM SNMPv2-TC 
FROM IF-MIB 
FROM SNMPv2 - CONF ; 
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Emulation Interworking Function (Version 1.0) 
Note: The new Version 2 CES MIB replaces this earlier 
Version 1 CES MIB which exists as the (deprecated) 
first branch from the overall atmfCESmib object." 
: : = { atmfCESmib 2 } 

atmForum OBJECT IDENTIFIER ::= j enterprises 353 } 

atmForumNetworkManagement OBJECT IDENTIFIER : := {atmForum 5 } 
atmfCESmib OBJECT IDENTIFIER { atmForumNetworkManagement 2 } 

--An OBJECT IDENTIFIER for all ATM Forum circuit emulation MIBs 
-- has been assigned as a branch from the ATM Forum Network 
-- Management tree. This MIB for the version 2 ATM Forum Circuit 
-- Emulation specification is attached as the second branch from the 
-- overall atmfCESmib object. 



-- The following TEXTUAL -CONVENTIONS are used to link the CES 
-- interworking function to ATM interface port, plus the 
associated VPI and VCI . 

Vpilnteger :: = TEXTUAL -CONVENT ION 
STATUS current 
DESCRIPTION 

"An integer large enough to hold a VPI" 
SYNTAX INTEGER (0..4095) 

Vcilnteger ::= TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 

"An integer large enough to hold a VCI" 
SYNTAX INTEGER (0.. 65535) 

CESConnectionPort ::= TEXTUAL -CONVENTION 
STATUS current 
DESCRIPTION 

"Indicates the port associated with a Circuit Emulation 
connection. Objects of this type are always defined as 
part of a set that includes 

fooPort CESConnectionPort 

fooVpi Vpilnteger 

fooVci Vcilnteger 
The interpretation of these objects is as follows: 

1. If no connection exists, 'fooPort' has a value of 0. 
Because Interface table entries always have 'if Index' 
values greater than 0, 'fooPort' reliably serves as a 
'connection exists 1 flag. 

If no connection exists, ' f ooVpi ■ and ' f ooVci ' are 
not relevant and have a value of 0. 

2. If a PVC or SVC exists, 'fooPort' is defined to have 
the value of the MIB- II/RFC1573 'if Index* of the ATM 
interface associated with the VCC. The if Type 
associated with such an iflndex value is either 
atm(37) or atmLogical (80) . ■ f ooVpi ' and 1 f ooVci ' 
will contain its VPI/VCI." 

SYNTAX INTEGER ( 0 .. 2147483647 ) 



AtmAddr ::= TEXTUAL -CONVENT I ON 
DISPLAY-HINT "lx" 
STATUS current 
DESCRIPTION 

"The ATM address used by the network entity. The address 
types are: no address (0 octets), E.164 (8 octets), and 
NSAP-encoded ATM Endsystem Address (20 octets) . 
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Note: The E.164 address is encoded in BCD format." 
SYNTAX OCTET STRING (SIZE (0 | 8 | 20) ) 

-- This is the MIB module for the ATM Forum Circuit Emulation 
-- Service Interoperability Specification Version 2.0. 

-- This MIB contains four tables: 
CES Configuration Table 
CES Mapping Table 
CES Statistics Table 
CES Active SVC Table 



-- CES Configuration Table 

atmfCESObjects OBJECT IDENTIFIER ::= {atmfCES l} 

a tmf CESConf Tab 1 e OBJECT - TYPE 

SYNTAX SEQUENCE OF Atmf CESConf Entry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"The CES configuration table used to manage interworking 
between CBR interfaces or channels and ATM Virtual Channel 
Links (VCLs) . The reverse mapping is shown in the 
atmf CESMappingTable . " 
::= { atmfCESObjects 1 } 

atmf CESConf Entry OBJECT-TYPE 
SYNTAX Atmf CESConf Entry 
MAX- ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"An entry in the CES configuration table. There is one 
entry in the table per CES entity, mapping one CBR 
interface, channel, or bundle to an ATM VCL. 

' Creation of a row in this table with a non-zero 
atmf CESAtmlndex causes a corresponding entry in the 
atmVclTable of the ATM- MIB (RFC1695) to be created." 
* INDEX { atmfCESCbrlndex } 
::= { atmf CESConf Table 1 } 

Atmf CESConf Entry ::= SEQUENCE { 
' atmfCESCbrlndex 
atmf CESAtmlndex 
atmf CESAtmVpi 
atmfCESAtmVci 
atmf CESCbrService 
atmfCESCbrClockMode 
atmfCESCas 
atmfCESPartialFill 
atmf CESBufMaxSize 
atmf CES CdvRxT 

atmfCESCellLossIntegrationPeriod 
atmf CESConnType 
atmf CESLocalAddr 
atmf CESAdminStatus 
atmf CESOperStatus 
atmf CESConf RowS tatus 

} 

atmfCESCbrlndex OBJECT-TYPE 



Interface Index, 

CESConnectionPort , 

Vpilnteger, 

Vcilnteger, 

INTEGER, 

INTEGER, 

INTEGER, 

INTEGER, 

INTEGER, 

INTEGER, 

INTEGER, 

INTEGER, 

AtmAddr , 

INTEGER, 

INTEGER, 

RowStatus 
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SYNTAX Interf acelndex 

MAX- ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"The value of this object is equal to MIB II' s if Index value 
of the CBR interface, channel, or bundle that is being 
cross-connected to an ATM VCL." 

{ atmf CESConf Entry 1 } 

atmfCESAtmlndex OBJECT-TYPE 
SYNTAX CESConnectionPort 
MAX- ACCESS read- create 
STATUS current 
DESCRIPTION 

"The value of this object is equal to MIB II' s 
iflndex value of the ATM Port interface mapped 
through this CES IWF to a CBR interface. This value 
is overwritten whenever an active or passive SVC is 
established . 

The distinguished value zero indicates that no ATM 
interface has been specified." 
::= { atmf CESConf Entry 2 } 

atmfCESAtmVpi OBJECT-TYPE 
SYNTAX Vpi Integer 

MAX-ACCESS read- create 
STATUS current 
DESCRIPTION 

"The value of this object is equal to the VPI used 
by the ATM VCL mapped through this CES IWF to a CBR 
interface. This value is overwritten whenever an 
active or passive SVC is established. 

The value is not relevant if no ATM interface has been 
specified (i.e., atmfCESAtmlndex is set to zero)." 
: : = { atmf CESConf Entry 3 } 

atmfCESAtmVci OBJECT-TYPE 
SYNTAX Vci Integer 

MAX- ACCESS read-create 
STATUS current 
DESCRIPTION 

"The value of this object is equal to the VCI used 
by the ATM VCL mapped through this CES IWF to a CBR 
interface. This value is overwritten whenever an 
active or passive SVC is established. 

The distinguished value zero indicates that no ATM 
VCL has been specified." 
: : = { atmf CESConf Entry 4 } 

atmfCESCbrService OBJECT-TYPE 
SYNTAX INTEGER { 

unstructured (1) , 
structured (2) 

} 

MAX -ACCESS read- create 
STATUS current 
DESCRIPTION 

"Define if DSx/Ex service isas structured or unstructurednot . A 
structured (2) interface is some nx64kbKbps. An unstructured 
(1) interface is 1.544Mbps, 2.048Mbps, 6.312Mbps, 44.736 Mbps, 
or 34.368 Mbps. unstructured (1 ) passes all bits through the 
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ATM network. strucutured (2 ) passes data bits through the 
ATM network, and may also pass signalling bits 

At this time, only unstructured mode is defined for the 
44.736 Mbps and 34.368 Mbps services." 
{ atmfCESConf Entry 5 } 

atmfCESCbrClockMode OBJECT -TYPE 

SYNTAX INTEGER { 

synchronous ( 1 ) , 
srts (2) , 
adaptive (3 ) 

MAX-ACCESS read- create 
STATUS current 
DESCRIPTION 

"Define if DSx/Ex service clocking mode. This maps into 
transmit clock source of CBR interface. 

For structured modes this value, if present, must be set to 

synchronous ( 1 ) . " 
DEFVAL { synchronous } 
: : = { atmfCESConf Entry 6 } 

atmfCESCas OBJECT-TYPE 
SYNTAX INTEGER { 

basic (1) , 
elCas (2) , 
dslSfCas{3) , 
dslEsfCas (4) , 
j2Cas (5) 
} 

MAX- ACCESS read- create 
STATUS current 
DESCRIPTION 

"This parameter selects which AAL1 Format should be used: 
Basic does not carry CAS bits, and uses a single 125 usee frame. 
elCas, dslSfCas, dSlEsfCas and j2Cas carry CAS bits in a 
multiframe structure for El, DS1 SF, DS1 ESF and J2 
respectively. 

This applies to structured interfaces only. Default is 

basic (1) . For unstructured interfaces this value, if present, 

must be set to the default of basic (1) ." 

DEFVAL { basic } 

::= { atmfCESConf Entry 7 } 

a tmf CES Par t i a 1 Fi 1 1 OBJECT - TYPE 

SYNTAX INTEGER (0 . . 47) 

MAX- ACCESS read- create 
STATUS current 
DESCRIPTION 

"If partial cell fill is used, the number of user octets per 
cell must be set with this parameter. Setting this parameter 
to zero disables partial cell fill, and causes all cells to 
be completely filled before they are sent." 

DEFVAL { 0 } -- Partial Cell Fill not used 

: : = { atmfCESConf Entry 8 } 

atmfCESBufMaxSize OBJECT-TYPE 

SYNTAX INTEGER (1.. 65536) 

UNITS "10 usee" 

MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
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"Define maximum size in 10 microsecond increments of the 
reassembly buffer. Some implementations may want allow the 
maximum buffer size to be programmed to a size less than the 
physical limit to reduce the maximum delay through a circuit." 

DEFVAL { 128 } 

::= { atmfCESConf Entry 9 } 

atmfCESCdvRxT OBJECT-TYPE 

SYNTAX INTEGER (1.. 65535) 

UNITS "10 usee" 

MAX- ACCESS read- create 
STATUS current 
DESCRIPTION 

"The maximum cell arrival jitter in 10 usee increments that 
the reassembly process will tolerate in the cell stream 
without producing errors on the CBR service interface." 

DEFVAL { 100 } 

::= { atmfCESConf Entry 10 } 

atmfCESCellLossIntegrationPeriod OBJECT-TYPE 
SYNTAX INTEGER (1000 . . 65535) 

UNITS "msec" 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"The time in milliseconds for the cell loss integration period. 

If a cells are continuously lost for this period of time, 

atmfCESCellLossStatus is set to loss (2) . The 

default definition is 2500." 
DEFVAL { 2500 } 
::= { atmfCESConf Entry 11 } 

atmfCESConnType OBJECT -TYPE 

SYNTAX INTEGER { 

other (1) , 
pvc (2) , 
activeSvc (3 ) , 
passiveSvc (4 ) 

MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"The type of ATM connectivity between associated CES IWF's. 
Valid values are: 

other - none of the types specified below 

pvc - supporting connectivity is a permanent 

virtual connection 
activeSvc - attempt calls whenever none established 
passiveSvc - accept calls" 
::= { atmfCESConf Entry 12 } 

atmfCESLocalAddr OBJECT-TYPE 
SYNTAX AtmAddr 
MAX- ACCESS read- create 
STATUS current 
DESCRIPTION 

"The ATM address of the local CES IWF process. This address 
may be used by the automatic SVC establishment procedures to 
identify the intended recipient CES IWF of an incoming automatic 
SVC call request. Optionally, the MAX-ACCESS of this object 
may be read-only, for those implementations where it is 
not desired to manually configure this address." 
::= { atmfCESConf Entry 13 } 
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atmfCESAdminStatus OBJECT-TYPE 
SYNTAX INTEGER { 

up(l) , 
down (2) 

} 

MAX- ACCESS read-create 
STATUS current 
DESCRIPTION 

"The desired administrative status of the CES interworking 
function. The up and down states indicate that the traffic 
flow is enabled or disabled respectively across the CES 
interworking function." 
::= { atmfCESConf Entry 14 } 

atmfCESOperStatus OBJECT-TYPE 
SYNTAX INTEGER { 

up(l) , 
down ( 2 ) , 
unknown ( 3 ) 
} 

MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"The operational status of the CES interworking function. 
The up and down states indicate that the traffic flow is 
enabled or disabled respectively across the CES interworking 
function. The unknown state indicates that the state of the 
CES interworking function cannot be determined. The state 
will be down or unknown if the supporting CBR or ATM 
interfaces are down or unknown, respectively." 
::= { atmfCESConf Entry 15 } 

atmfCESConf RowStatus OBJECT-TYPE 
SYNTAX RowStatus 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"This object is used to create new rows in this table, modify 
existing rows, and to delete existing rows." 
::= { atmfCESConf Entry 16 } 



-- CES Mapping Table 

atmfCESMappingTable OBJECT-TYPE 

SYNTAX SEQUENCE OF Atmf CESMappingEntry 

MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"The CES mapping table used to show the mapping from ATM 
VCLs to CBR interfaces or channels. The mapping and 
interworking functions are configured in the 
atmfCESConf Table. " 

{ atmfCESObjects 2 } 

atmf CESMappingEntry OBJECT-TYPE 

SYNTAX Atmf CESMappingEntry 

MAX- ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"An entry in the CES mapping table . There is one entry 
in the table corresponding to each active row in the 
atmf CESConf Table for which there is a non-zero 
atmf CESAtmlndex. " 
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INDEX { atmfCESAtmlndex, 

atmf CESAtmVpi , 

atmfCESAtmVci } 
::= { atmfCESMappingTable 1 } 

AtmfCESMappingEntry ::= SEQUENCE { 

atmfCESMappingCbrlndex Interface Index 

} 

atmfCESMappingCbrlndex OBJECT-TYPE 
SYNTAX Interf acelndex 

MAX- ACCESS read-only 
STATUS current 
DESCRIPTION 

"The value of this object is equal to MIB II' s if Index value 
of the CBR interface, channel, or bundle that is being 
cross-connected to an ATM VCL. Examples of the if Type 
value for the CBR entity are dsl(18), ds3 (30) , ds0(81), or 
ds0bundle(82) . " 
::= { atmf CESMappingEntry 1 } 



-- CES Statistics Table 

atmfCESStatsTable OBJECT-TYPE 

SYNTAX SEQUENCE OF Atmf CESStatsEntry 

MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"The CES AAL1 statistical data table." 

{ atmfCESObjects 3 } 

atmf CESStatsEntry OBJECT-TYPE 

SYNTAX Atmf CESStatsEntry 

MAX- ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"An entry in the CES AAL1 Stats table. There is one 
entry in this table corresponding to each entry in the 
atmf CESConf Table . 

AUGMENTS { atmf CESConf Entry } 

::= { atmfCESStatsTable 1 } 

Atmf CESStatsEntry :: = SEQUENCE { 

atmf CESReassCells Counter32 , 

atmf CESHdrErrors Counter32, 

atmf CESPointerRef rames Counter32 , 

atmf CESPointerParityErrors Counter32 , 

atmf CESAallSeqErrors Counter32 , 

atmf CESLostCells Counter32 , 

atmf CESMisinsertedCells Counter32 , 

atmf CESBuf Under flows Counter32 , 

atmf CESBuf Overflows Counter32 , 

atmfCESCellLossStatus INTEGER 
} 



atmf CESReassCells OBJECT-TYPE 
SYNTAX Counter 3 2 

MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"This count gives the number of cells played out to the 
CES Service Interface. It excludes cells that were 
discarded for any reason, including cells that were not used 
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due to being declared misinserted, or discarded while the 
reassembler was waiting to achieve synchronization." 
::= { atmfCESStatsEntry 1 } 



atmf CESHdrErrors 



OBJECT -TYPE 



SYNTAX 

MAX-ACCESS 

STATUS 



Counter32 
read-only 
current 



DESCRIPTION 

"The count of the number of AAL1 header errors detected, 
including those corrected. Header errors include correctable 
and uncorrectable CRC, plus bad parity." 

{ atmfCESStatsEntry 2 } 

atmfCESPointerRef rames OBJECT-TYPE 
SYNTAX Counter32 
MAX- ACCESS read-only 
STATUS current 
DESCRIPTION 

"This records the count of the number of events in which the 
AAL1 reassembler found that an SDT pointer is not where it is 
expected, and the pointer must be reacquired. This count is 
only meaningful for structured CES modes, as unstructured CES 
modes do not use pointers. For unstructured CES modes, this 
count, if present, should indicate zero." 
::= { atmfCESStatsEntry 3 } 

atmfCESPointerParityErrors OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"This records the count of the number of events in which the 
AAL1 reassembler detects a parity check failure at the point 
where a structured data pointer is expected. This count is only 
meaningful for structured CES modes, as unstructured CES modes 
do not use pointers. For unstructured CES modes, this count, if 
present, should indicate zero." 
::= { atmfCESStatsEntry 4 } 

atmfCESAallSeqErrors OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"Number of times that the sequence number of an incoming AAL1 
Type 1 SAR-PDU causes a transition from the 'sync' state to 
the 'out of sequence' state, as defined by ITU-T 1.3 63.1." 
::= { atmfCESStatsEntry 5 } 

atmfCESLostCells OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"Number of lost cells, as detected by the AAL1 sequence number 
processing, for example. This records the count of the number 
of cells detected as lost in the network prior to the 
destination CES IWF AAL1 layer processing." 
::= { atmfCESStatsEntry 6 } 

atmfCESMisinsertedCells OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
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STATUS current 
DESCRIPTION 

"Number of AAL1 sequence violations which the AAL Convergence 
sublayer interprets as a misinserted cell, as defined by 
ITU-T 1.363.1." 
::= { atmfCESStatsEntry 7 } 

atmfCESBuf Underflows OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"Number of buffer underflows. This records the count of the 
number of times the CES reassembly buffer underflows. In the 
case of a continuous underflow caused by a loss of ATM cell 
flow, a single buffer underflow should be counted. If the CES 
IWF is implemented with multiple buffers (such as a cell level 
buffer and a bit level buffer) , then either buffer underflow 
will cause this count to be incremented." 
::= { atmfCESStatsEntry 8 } 

atmfCESBuf Overflows OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"Number of buffer overflows. This records the count of the 
number of times the CES reassembly buffer overflows. If the CES 
IWF is implemented with multiple buffers (such as a cell level 
buffer and a bit level buffer, then either buffer overflow will 
cause this count to be incremented " 
::= { atmfCESStatsEntry 9 } 

atmfCESCellLossStatus OBJECT-TYPE 
SYNTAX INTEGER { 

noLoss (1) , 
loss (2) 
} 

MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"When cells are continuously lost for the number of milliseconds 
specified by atmf CESCellLossIntegrationPeriod, the value is set 
to loss (2) . When cells are no longer lost, the value is set 
to noLoss (1) . " 
::= { atmfCESStatsEntry 10 } 



-- CES Active SVC Table 

atmfCESActiveSvcTable OBJECT -TYPE 

SYNTAX SEQUENCE OF Atmf CESActiveSvcEntry 

MAX- ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"The table used to manage active SVCs established across ATM 
networks between CES entities." 
::= { atmf CESObjects 4 } 

atmf CES Ac t i ve S vcEnt ry OBJECT - TYPE 

SYNTAX Atmf CESActiveSvcEntry 

MAX- ACCESS not -accessible 
STATUS current 
DESCRIPTION 
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"An entry in the CES active SVC table. There is one 
entry in the table corresponding to each active row in 
the atmfCESConfTable for which the atmf CESConnType takes 
the value * activeSvc ' . " 

INDEX { atmfCESCbrlndex } 

::= { atmfCESActiveSvcTable 1 } 



AtmfCESActiveSvcEntry ::= SEQUENCE { 
atmf CESRemoteAddr 
atmf CESFirstRetrylnterval 
atmfCESRetryTimer 
atmf CESRetryLimit 
atmfCESRetryFailures 
atmf CESActiveSvcRestart 
atmf CESActiveSvcOperStatus 
atmf CESLastReleaseCause 
atmf CESLastReleaseDiagnos tics 



AtmAddr , 
INTEGER, 
INTEGER, 
INTEGER, 
Gauge 3 2 , 
INTEGER, 
INTEGER, 
INTEGER, 
OCTET STRING 



} 



OBJECT-TYPE 



atmf CESRemoteAddr 

SYNTAX AtmAddr 
MAX-ACCESS read- write 
STATUS current 
DESCRIPTION 

"The ATM address supporting the corresponding far end 
CES IWF process. If no address is supplied, no attempts 
to establish the active SVC are initiated." 
::= { atmfCESActiveSvcEntry 1 } 

atmf CESFirstRetrylnterval OBJECT-TYPE 
SYNTAX INTEGER (1..3600) 

UNITS "seconds" 
MAX-ACCESS read- write 
STATUS current 
DESCRIPTION 

"The time to wait before attempting to establish the SVC 
after the first failed call attempt. The time to wait 
between subsequent call attempts may differ to implement 
a backoff scheme. Zero represents an infinite interval 
indicating no retries." 
DEFVAL { 10 } 

::= { atmfCESActiveSvcEntry 2 } 



OBJECT -TYPE 
,86400) 



atmfCESRetryTimer 

SYNTAX INTEGER (0. 

UNITS "seconds" 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"Indicates the current value of the retry timer for 
this connection. When the value reaches zero an attempt 
will be made to establish the active SVC. When the timer 
is not running, the value zero shall be returned." 

{ atmfCESActiveSvcEntry 3 } 



OBJECT-TYPE 
.65535) 



atmf CESRetryLimit 

SYNTAX INTEGER (0. 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"Sets a maximum limit on how many consecutive unsuccessful 
call setup attempts can be made before stopping the attempt 
to set up the connection. If this limit is reached then 
management action will be required (e.g. setting 
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atmfCESActiveSvcRestart to 'restart') to initiate a new 
attempt to establish the connection. A value of zero 
indicates no limit - the attempts will continue until 
successful. If this object is not present, no limit on call 
attempts is assumed." 
DEFVAL { 0 } 

::= { atmfCESActiveSvcEntry 4 } 

atmfCESRetryFailures OBJECT-TYPE 
SYNTAX Gauge 3 2 

MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"Indicates how many attempts to establish the connection 
have failed. This count is reset whenever a connection 
is successfully established or the active SVC is restarted." 
::= { atmfCESActiveSvcEntry 5 } 

a tmf CESAc t i ve S vcRe start OBJECT - TYPE 

SYNTAX INTEGER { 

restart (1) , 
noop ( 2 ) 

MAX-ACCESS read- write 
STATUS current 
DESCRIPTION 

"When the value is set to 'restart* the active SVC 
is released if necessary and a new setup procedure 
is begun. As a result of this action, the 
atmf CESActiveSvcOperStatus object transitions to 
■ establishmentlnProgress ' (if not already in this state) 
and the atmfCESRetryFailures object is cleared. 

When the value is set to *noop' no operation is 
performed. When read, the value 'noop' is returned." 
::= { atmfCESActiveSvcEntry 6 } 

atmf CESActiveSvcOperStatus OBJECT-TYPE 
SYNTAX INTEGER { 

other (1) , 

establishmentlnProgress (2) , 
connected (3) , 
retriesExhausted(4) , 
noAddress Supplied (5) , 
lower Layer Down ( 6 ) 
} 

MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"Describes the status of the active SVC. Valid values are: 
other - none of the types specified below 

establishmentlnProgress - connection is not operational, 

but call attempts are ongoing 
connected - connection is currently operational 

retriesExhausted - retry limit has been reached and call 

attempts have ceased 
noAddress Supplied - no remote address has been configured, 

so no call attempts are initiated 
lower Layer Down - underlying CES IWF is not operational 

When the row is not 'active', the value of this object is 
1 other • . " 
::= { atmfCESActiveSvcEntry 7 } 
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atmfCESLastReleaseCause OBJECT -TYPE 

SYNTAX INTEGER (1 . .127) 

MAX- ACCESS read-only 
STATUS current 
DESCRIPTION 

"Value of the Cause field of the Cause information element 
in the last RELEASE signalling message received for this 
active SVC. Indicates the reason for the release." 
::= { atmfCESActiveSvcEntry 8 } 

atmfCESLastReleaseDiagnostics OBJECT-TYPE 
SYNTAX OCTET STRING (SIZE(0..8)) 

MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"Value of the first 8 bytes of diagnostic information 
from the Cause field of the Cause information element 
in the last RELEASE signalling message received for this 
active SVC. " 
::= { atmfCESActiveSvcEntry 9 } 



-- Conformance Information 

atmfCESConformance OBJECT IDENTIFIER ::= { atmfCES 2 } 

atmfCESGroups OBJECT IDENTIFIER ::= { atmfCESConformance 1 ) 

atmfCESCompliances OBJECT IDENTIFIER ::= { atmfCESConformance 2 } 

-- Compliance Statements 

atmfCESCompliance MODULE -COMPLIANCE 

STATUS current 
DESCRIPTION 

"The compliance statement for SNMP entities which support 
the ATM Forum Circuit Emulation Services . " 

MODULE this module 

MANDATORY -GROUPS { 

atmf CESBasicConf igGroup, 

atmf CESBasicStatsGroup 

} 

GROUP atmfCESStruct Con f i gGr oup 

DESCRIPTION "This group is mandatory only for IWFs that 

support Structured DS1, El or J2 Nx64 kbit/s 
Service . " 

GROUP atmfCESStructStatsGroup 

DESCRIPTION "This group is mandatory only for IWFs that 

support Structured DS1, El or J2 Nx64 kbit/s 
Service . " 

GROUP atmf CESSvcConf igGroup 

DESCRIPTION "This group is mandatory only when support for 

automatic SVC initiation procedures is provided." 

OBJECT atmfCESLocalAddr 
MIN- ACCESS read-only 

DESCRIPTION "Support for manual configuration of the local 

CES interworking function address is not 
required. " 

: := { atmfCESCompliances 1 } 
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Units of Conformance 

atmfCESBasicConf igGroup OBJECT - GROUP 
OBJECTS { 

atmf CESAtmlndex , 
atmf CESAtmVpi , 
atmfCESAtmVci, 
atmf CESCbrService , 
atmf CESCbrClockMode , 
atmf CESBuf MaxSi ze , 
atmfCESCdvRxT, 

atmf CESCellLossIntegrationPeriod, 
atmf CESConnType , 
atmf CESConfRowStatus 

} 

STATUS current 
DESCRIPTION 

"A collection of objects providing configuration information 
for generic Circuit Emulation Service IWFs . " 
: : = { atmf CESGroups 1 } 

atmfCESOptionalConf igGroup OBJECT-GROUP 
OBJECTS { 

atmf CESAdminStatus , 
atmf CESOperStatus 

} 

STATUS current 
DESCRIPTION 

"A collection of optional objects providing configuration 
information for generic Circuit Emulation Service IWFs." 
::= { atmf CESGroups 2} 

atmfCESBasicStatsGroup OBJECT - GROUP 
OBJECTS { 

atmf CESReassCells , 
atmf CESHdrErrors , 
atmf CESBuf Underflows , 
atmf CESBuf Overflows , 
atmf CESCellLossStatus 

} 

STATUS current 
DESCRIPTION 

"A collection of objects providing statistics information 
for generic Circuit Emulation Service IWFs." 
: : = { atmf CESGroups 3 } 

atmfCESOptionalStatsGroup OBJECT-GROUP 
OBJECTS { 

atmf CESAallSeqErrors , 

atmfCESLostCells, 

atmf CESMisinsertedCells 

} 

STATUS current 
DESCRIPTION 

"A collection of optional objects providing statistics 
information for generic Circuit Emulation Service IWFs." 
: : = { atmf CESGroups 4 } 

atmf CES S t rue t Conf igGroup OBJECT - GROUP 
OBJECTS { 

atmfCESCas, 
atmfCESPartialFill 

} 
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STATUS current 
DESCRIPTION 

"A collection of objects providing 
for Structured DS1, El or J2 Nx64 
: : = { atmf CESGroups 5 } 

atmfCESStructStatsGroup OBJECT-GROUP 
OBJECTS { 

atmf CESPointerRe frames 

} 

STATUS current 
DESCRIPTION 

"A collection of objects providing statistics information 
for Structured DS1, El or J2 Nx64 kbit/s Service IWFs . " 
: : = { atmf CESGroups 6 } 

atmfCESOptionalStructStatsGroup OBJECT-GROUP 
OBJECTS { 

atmfCESPointerParityErrors 

} 

STATUS current 
DESCRIPTION 

"A collection of optional objects providing statistics 
information for Structured DS1, El or J2 Nx64 kbit/s Service 
IWFs . " 
: : = { atmf CESGroups 7 } 

atmfCESMappingGroup OBJECT-GROUP 
OBJECTS { 

atmf CESMappingCbr Index 

} 

STATUS current 
DESCRIPTION 

"A collection of objects providing information about the 
mapping from ATM VCLs to CBR interfaces or channels." 
: : = { atmf CESGroups 8 } 

atmfCESSvcConf igGroup OBJECT-GROUP 
OBJECTS { 

atmf CESLocalAddr , 

a tmf CESRemoteAddr , 

atmf CESFirstRetrylnterval , 

atmfCESRetryTimer, 

atmf CESRetryFailures , 

atmf CESActiveSvcRestart , 

atmf CESActiveSvcOperStatus 

} 

STATUS current 
DESCRIPTION 

"A collection of objects providing SVC connection 
establishment support configuration information for CES 
IWFs . " 
: : = { atmf CESGroups 9 } 

atmfCESOptionalSvcConf igGroup OBJECT-GROUP 
OBJECTS { 

atmf CESRetryLimit , 

atmf CESLastReleaseCause, 

atmf CESLastReleaseDiagnos tics 

} 

STATUS current 
DESCRIPTION 

"A collection of optional objects providing SVC connection 
establishment support configuration information for CES 



configuration information 
kbit/s Service IWFs." 
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IWFs . " 

::= { atmf CESGroups 10 } 

END 
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Annex A: Impairment Analysis 

This annex addresses the mapping into Circuit Emulation Service impairments — errored 
seconds (ES) and severely errored seconds (SES) — from the cell loss ratio (CLR) and the 
cell error rate (CER) impairments of the underlying ATM transport. It complements the 
broader, more qualitative discussion in the (informative) Annex B, "Relationship between 
ATM Layer Network Performance and the Network Performance of AAL Type 1 for CBR 
Services", of T1.51 1-1994, "B-ISDN ATM Layer Cell Transfer - Performance 
Parameters" 

It is difficult to set requirements on these impairments and other impairments such as cell 
transfer delay (CTD) and cell delay variation (CDV), since they are application specific; 
and in some cases, particularly CDV, still being studied. Furthermore, the requirements 
could be equipment dependent. For example, the addition of error control to equipment 
would decrease requirements on the ATM transport facility. 

For DS1 and fractional DS1, there are some requirements in ANSI T1.510 for SES and 
ES. When voice was the predominate application, one could, assuming no error control, 
derive some reasonable requirements for BER since an end-to-end PCM-encoded voice 
signal would tolerate a 10" 6 BER in the TDM circuit.(Source: SR-TSV-00275, Iss. 1, 
March 1991). 

The following discussion of ES and SES assumes an absence of error control on the cell 
information field and that lost cells are replaced with a random bit pattern. 

A.l Errored Second 

An ES is a one-second interval with one or more bit errors. Each Nx64 kbit/s and 1.544 
Mbit/ s channel requires that, over 30 or more consecutive days, fewer than 0.20% and 
0.50%, respectively, of the seconds are errored seconds. (Source: ANSI Tl. 510-1994) 

Since 64 kbit/s and even 1 .544 Mbit/s channels are likely a small proportion of the 
underlying ATM transport capacity, then the burstiness of ATM-related binary errors and 
cell loss should be dispersed in time at both the 64 kbit/s and the 1.544 Mbit/s channel 
levels. Therefore, the worst case approach of random errors and cell loss may be 
reasonable. If so, then, ignoring the small (2 -376 ) probability that a cell loss will cause no 
binary errors: 

For a 64 kbit/s channel (which utilizes 170.21 cell/s), an ES less than 0.20% (or 1 in 500) 
of the seconds implies that CER + CLR < 1.175 x 10" 5 ; 

For an Nx64 kbit/s channel (which utilizes Nx 170.21 cell/s, 2 < N < 24), an ES less than 
0.20% (or 1 in 500) of the seconds implies that CER + CLR < 1.175 x 10" 5 /N; 

For a 2.048 Mbit/s channel (which utilizes 5,447 cell/s) an ES less than 0.50% (or 1 in 
200) of the seconds implies that CER + CLR < 9.18 x 10" 7 . 

These ATM performance parameters map into DS1 Bit Error Rate (BER), Errored Second 
(ES) and Severely Errored Second (SES) values: 
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Cell Error Ratio (CER) - an errored bit in a cell payload is likely to result in an error in the 
emulated circuit, causing an Errored Second. 

Cell Loss Ratio (CLR) - a lost cell will result in an average of 188 errored bits in the 
emulated circuit. A single lost cell will result in a Severely Errored Second for Nx64 
services where N is one or two. 

Cell Misinsertion Rate (CMR) - undetected, misinserted cells will also cause Severely 
Errored Seconds for Nx64 circuits where N is one or two. 

We summarize the mapping outlined above in Table A-l. 



Service 


Performance 


ATM 




Target 


Objective 


unstructured DS1 


ES < 0.5% 


CLR+CER< 1.22xl0- 6 


unstructured El 


ES < 0.5% * 


CLR+CER<9.18xlO" 7 


64 kbit/s 


ES < 0.2% 


CLR+CER< 1.175xl0- 5 



Table A-l: ATM VC Mapping 
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Annex B Abbreviations 

Acronyms and abbreviations in CES baseline document: 

AAL - ATM Adaptation Layer 

AAL1 - ATM Adaptation Layer Type 1 

AIS - Alarm Indication Signal 

AMI - Alternate Mark Inversion 

ANSI - American National Standards Institute 

ATM - Asynchronous Transfer Mode 

AUU - ATM-Layer-User to ATM-Layer-User 

B-HLI - Broadband High Layer Information 

B-LLI - Broadband Low Layer Information 

B-ICI - Broadband Intercarrier Interface 

B-ISDN - Broadband Integrated Services Digital Network 

B8ZS - Bipolar with 8 Zero Substitution 

BER - Bit Error Ratio 

BITS - Building Integrated Timing System 

CAS - Channel Associated Signalling 

CBR - Constant Bit Rate 

CDV - Cell Delay Variation 

CE - Congestion Experienced 

CER - Cell Error Ratio 

CES - Circuit Emulation Service 

CES-IS - Circuit Emulation Service Interoperability Specification 

CLP - Cell Loss Priority 

CLR - Cell Loss Ratio 

CMR - Cell Misinsertion Ratio 

CO - Central Office 

CRC - Cyclic Redundancy Check 

CTD - Cell Transfer Delay 

DSO - Digital Signal level 0 (64 kbit/s) 

DS1 - Digital Signal level 1 (1544 kbit/s) 

DS3 - Digital Signal level 3 (44736 kbit/s) 

DSX1 - Digital Signal Cross(X)connect level 1 

El - special digital trunk, European (2048 kbit/s) 
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E3 - Special Digital Trunk, European (34.368 Mbit/s) 

ES - Errored Second 

ESF - Extended Super Frame 

FDL - Facility Data Link 

HDB3 - High-Density Binary Three 

IE - Information Element 

IEC - International Electrotechnical Commission 

IETF - Internet Engineering Task Force 

ILMI - Interim Local Management Interface 

ISDN - Integrated Services Digital Network 

ISO - International Organization for Standardization 

IWF - Inter- Working Function 

J2 - Japanese standard for 6.312 Mbit/s electrical PDH transmission (Note: this J2 acronym 
is used by the ATM Forum for this service. The Japanese TTC does not use the J2 
acronym.) 

kbit/s - thousand bits per second 

LOS - Loss of Signal 

Mbit/s - million bits per second 

MIB - Management Information Base 

ms - milliseconds 

(isec - microsecond 

N-ISDN - Narrowband Integrated Services Digital Network 

NNI - Network to Network Interface 

OAM - Operations And Maintenance 

0C3 - Optical Carrier level 3 (155.52 Mbit/s) 

OUI - Organizational Unit Identifier 

PBX - Private Branch eXchange 

PCM - Pulse Code Modulation 

PCR - Peak Cell Rate 

PDH - Plesiochronous Digital Hierarchy 

PLCP - Physical Layer Convergence Protocol 

POTS - Plain Old Telephone Service 

ppm - parts per million 

PRS - Primary Reference Source 

QoS - Quality of Service 

RAI - Remote Alarm Indication 

RFC - Request for Comment 
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SAA - Service Aspects and Applications 
SDH - Synchronous Digital Hierarchy 
SDT - Structured Data Transfer 
SDU - Service Data Unit 
SES - Severely Errored Second 
SF - Super Frame 

SNAP - Sub-Network Access Protocol 

SNMP - Simple Network Management Protocol 

SONET - Synchronous Optical NETwork 

SRTS - Synchronous Residual Time Stamp 

SVC - Switched virtual circuit 

TDM - Time Division Multiplex 

UDT - Unstructured Data Transfer 

UI - Unit Interval 

UNI - User to Network Interface 

UPC - Usage Parameter Control 

VC - Virtual Channel 

VCC - Virtual Channel Connection 
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